From volker.simonis at gmail.com Thu Jan 2 09:22:59 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Jan 2014 18:22:59 +0100 Subject: RFR(S): JDK-8031134 : PPC64: implement printing on AIX Message-ID: Hi, could somebody please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8031134/ It's the straight forward implementation of the basic printing infrastructure on AIX and shouldn't have any impact on the existing platforms. As always, this change is intended for the http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. Thank you and best regards, Volker From Alan.Bateman at oracle.com Thu Jan 2 12:15:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jan 2014 20:15:31 +0000 Subject: RFR(S): JDK-8031134 : PPC64: implement printing on AIX In-Reply-To: References: Message-ID: <52C5C8E3.8020503@oracle.com> On 02/01/2014 17:22, Volker Simonis wrote: > Hi, > > could somebody please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8031134/ > > It's the straight forward implementation of the basic printing > infrastructure on AIX and shouldn't have any impact on the existing > platforms. As always, this change is intended for the > http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. > cc'ing 2d-dev as that is where the printing code is maintained. Your changes suggest that this code should probably be refactored at some point to make it easier to add other Unix variants. -Alan From vladimir.kozlov at oracle.com Mon Jan 6 10:04:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jan 2014 10:04:47 -0800 Subject: RFR(XS): 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8A4D2@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8A4D2@DEWDFEMB12A.global.corp.sap> Message-ID: <52CAF03F.6050503@oracle.com> Looks good. Vladimir On 1/6/14 2:14 AM, Lindenmaier, Goetz wrote: > A happy new year everybody! > > Could you please review and test this tiny fix? > > It?s in code so far only used by ppc64. > > http://cr.openjdk.java.net/~goetz/webrevs/8031188-nc/ > > fixup_flow can add new blocks with a branch instruction. Doing > so after a trap based check added the branch behind the wrong > Proj node. The branch would jump to the proper target, but build_oop_map > analyses a wrong control flow. > > Fix: Swap the Projs in the block list so that the new block is added behind > the proper node. > > Thanks & best regards, > > Goetz > From goetz.lindenmaier at sap.com Mon Jan 6 02:14:50 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Jan 2014 10:14:50 +0000 Subject: RFR(XS): 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8A4D2@DEWDFEMB12A.global.corp.sap> A happy new year everybody! Could you please review and test this tiny fix? It's in code so far only used by ppc64. http://cr.openjdk.java.net/~goetz/webrevs/8031188-nc/ fixup_flow can add new blocks with a branch instruction. Doing so after a trap based check added the branch behind the wrong Proj node. The branch would jump to the proper target, but build_oop_map analyses a wrong control flow. Fix: Swap the Projs in the block list so that the new block is added behind the proper node. Thanks & best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140106/ff9bcf56/attachment.html From goetz.lindenmaier at sap.com Mon Jan 6 02:16:50 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Mon, 06 Jan 2014 10:16:50 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: ppc: Fix issue in trap based null check optimization Message-ID: <20140106101706.A15CD623DE@hg.openjdk.java.net> Changeset: 3cc52fb61873 Author: goetz Date: 2014-01-06 10:50 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/3cc52fb61873 ppc: Fix issue in trap based null check optimization ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp From vladimir.kozlov at oracle.com Mon Jan 6 16:45:42 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 07 Jan 2014 00:45:42 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks Message-ID: <20140107004546.D9E94623FD@hg.openjdk.java.net> Changeset: 4345c6a92f35 Author: goetz Date: 2014-01-06 11:02 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/4345c6a92f35 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks Summary: Swap the Projs in the block list so that the new block is added behind the proper node. Reviewed-by: kvn ! src/share/vm/opto/block.cpp From david.holmes at oracle.com Mon Jan 6 22:33:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 16:33:18 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> Message-ID: <52CB9FAE.80800@oracle.com> Hi Goetz, Happy New year! :) I'm backing up a step now that I have a better grip on the IRIW issue. On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: > Hi, > > ok, I understand the tests are wrong. It's good this issue is settled. > Thanks Aleksey and Andreas for going into the details of the proof! > > About our change: David, the causality is the other way round. > The change is about IRIW. > 1. To pass IRIW, we must use sync instructions before loads. Okay I see this (though I think we need to kill IRIW as a requirement and I don't think IRIW should form part of any conformance test). > 2. If we do syncs before loads, we don't need to do them after stores. True for the IRIW case but to prevent local reordering of volatile stores don't you still need some form of "storestore" barrier? initially: x = 0; y = 0 Thread 0: Thread 1: x = 1 r1 = x y = 1 r2 = y --------------------------- Should be Forbidden: r1 = 0 ^ r2 = 1 You can add the sync after each read but that doesn't prevent the stores in thread 0 from being locally re-ordered. So I think you still need at least lwsync on the writer side: initially: x = 0; y = 0 Thread 0: Thread 1: x = 1 r1 = x lwsync sync y = 1 r2 = y sync --------------------------- Forbidden: r1 = 0 ^ r2 = 1 David ----- > 3. If we don't do them after stores, we fail the volatile constructor tests. > 4. So finally we added them again at the end of the constructor after stores > to pass the volatile constructor tests. > > We originally passed the constructor tests because the ppc memory order > instructions are not as find-granular as the > operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction > on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the > MemBarVolatile after the store fixes the constructor tests. The proper representation > of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless > anyways. > >> I'm not happy with the ifdef approach but I won't block it. > I'd be happy to add a property > OrderAccess::cpu_is_multiple_copy_atomic() > or the like to guard the customization. I'd like that much better. Or also > OrderAccess::needs_support_iriw_ordering() > VM_Version::needs_support_iriw_ordering() > > > Best regards, > Goetz. > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 28. November 2013 00:34 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > TL;DR version: > > Discussion on the c-i list has now confirmed that a constructor-barrier > for volatiles is not required as part of the JMM specification. It *may* > be required in an implementation that doesn't pre-zero memory to ensure > you can't see uninitialized fields. So the tests for this are invalid > and this part of the patch is not needed in general (ppc64 may need it > due to other factors). > > Re: "multiple copy atomicity" - first thanks for correcting the term :) > Second thanks for the reference to that paper! For reference: > > "The memory system (perhaps involving a hierarchy of buffers and a > complex interconnect) does not guarantee that a write becomes visible to > all other hardware threads at the same time point; these architectures > are not multiple-copy atomic." > > This is the visibility issue that I referred to and affects both ARM and > PPC. But of course it is normally handled by using suitable barriers > after the stores that need to be visible. I think the crux of the > current issue is what you wrote below: > > > The fixes for the constructor issue are only needed because we > > remove the sync instruction from behind stores (parse3.cpp:320) > > and place it before loads. > > I hadn't grasped this part. Obviously if you fail to do the sync after > the store then you have to do something around the loads to get the same > results! I still don't know what lead you to the conclusion that the > only way to fix the IRIW issue was to put the fence before the load - > maybe when I get the chance to read that paper in full it will be clearer. > > So ... the basic problem is that the current structure in the VM has > hard-wired one choice of how to get the right semantics for volatile > variables. You now want to customize that but not all the requisite > hooks are present. It would be better if volatile_load and > volatile_store were factored out so that they could be implemented as > desired per-platform. Alternatively there could be pre- and post- hooks > that could then be customized per platform. Otherwise you need > platform-specific ifdef's to handle it as per your patch. > > I'm not happy with the ifdef approach but I won't block it. I think this > is an area where a lot of clean up is needed in the VM. The barrier > abstractions are a confused mess in my opinion. > > Thanks, > David > ----- > > On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated the webrev to fix the issues mentioned by Vladimir: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >> >> I did not yet add the >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> or >> OrderAccess::cpu_is_multiple_copy_atomic() >> to reduce #defined, as I got no further comment on that. >> >> >> WRT to the validity of the tests and the interpretation of the JMM >> I feel not in the position to contribute substantially. >> >> But we would like to pass the torture test suite as we consider >> this a substantial task in implementing a PPC port. Also we think >> both tests show behavior a programmer would expect. It's bad if >> Java code runs fine on the more common x86 platform, and then >> fails on ppc. This will always first be blamed on the VM. >> >> The fixes for the constructor issue are only needed because we >> remove the sync instruction from behind stores (parse3.cpp:320) >> and place it before loads. Then there is no sync between volatile store >> and publishing the object. So we add it again in this one case >> (volatile store in constructor). >> >> >> @David >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> It may have started a year ago but work on it has hardly been continuous. >> That's not true, we did a lot of investigation and testing on this issue. >> And we came up with a solution we consider the best possible. If you >> have objections, you should at least give the draft of a better solution, >> we would volunteer to implement and test it. >> Similarly, we invested time in fixing the concurrency torture issues. >> >> @David >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >> We learned about this reading "A Tutorial Introduction to the ARM and >> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >> >> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >> instead. Sorry for that. (I also fixed that in the method name above). >> >> Best regards and thanks for all your involvements, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 27. November 2013 12:53 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> -- Volatile in constuctor >>>> AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>> We see them on PPC64. Our test machines have typically 8-32 processors >>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >> >> And see follow ups - the tests are invalid. >> >>> -- IRIW issue >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> >> It may have started a year ago but work on it has hardly been continuous. >> >>>> You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>> solution with the #defines, and that's correct for all, but not nice, I admit. >>> (I don't really know about ARM, though). >>> So if I can write down a nicer solution testing for methods that are evaluated >>> by the C-compiler I'm happy. >>> >>> The problem is not that IRIW is not handled by the JMM, the problem >>> is that >>> store >>> sync >>> does not assure multiple-read-atomicity, >>> only >>> sync >>> load >>> does so on PPC. And you require multiple-read-atomicity to >>> pass that test. >> >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. >> >> Thanks, >> David >> >> The JMM is fine. And >>> store >>> MemBarVolatile >>> is fine on x86, sparc etc. as there exist assembler instructions that >>> do what is required. >>> >>> So if you are off soon, please let's come to a solution that >>> might be improvable in the way it's implemented, but that >>> allows us to implement a correct PPC64 port. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 1:11 PM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>> Hi everybody, >>>> >>>> thanks a lot for the detailed reviews! >>>> I'll try to answer to all in one mail. >>>> >>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>> We don't think it's correct if we omit the barrier after initializing >>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>> and Doug Lea, and they agreed. >>>> Also, concurrency torture tests >>>> LongVolatileTest >>>> AtomicIntegerInitialValueTest >>>> will fail. >>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>> >>> The affects of unsafe publication are always surprising - volatiles do >>> not add anything special here. AFAIK there is nothing in the JMM that >>> requires the constructor barrier - discussions with Doug and Aleksey >>> notwithstanding. AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >>> >>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>> see a way to implement this cheaper. >>>> >>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>> Basically, I agree on this. But you also have to take into account >>>> that due to the different memory ordering instructions on different platforms >>>> just implementing something empty is not sufficient. >>>> An example: >>>> MemBarRelease // means LoadStore, StoreStore barrier >>>> MemBarVolatile // means StoreLoad barrier >>>> If these are consecutively in the code, sparc code looks like this: >>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>> Just doing what is required. >>>> On Power, we get suboptimal code, as there are no comparable, >>>> fine grained operations: >>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>> I need an additional optimization that removes the lwsync. I can not implement >>>> MemBarRelease empty, as it is also used independently. >>>> >>>> Back to the IRIW problem. I think here we have a comparable issue. >>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>> is inefficient on platforms that have multiple-read-atomicity. >>>> >>>> I would propose to guard the code by >>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>> OrderAccess::cpu_is_multiple_read_atomic() >>>> Else, David, how would you propose to implement this platform independent? >>>> (Maybe we can also use above method in taskqueue.hpp.) >>> >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so >>> different?) and I can not take that on face value at the moment. The >>> only reason I can see IRIW not being handled by the JMM requirements for >>> volatile accesses is if there are global visibility issues that are not >>> addressed - but even then I would expect heavy barriers at the store >>> would deal with that, not at the load. (This situation reminds me of the >>> need for read-barriers on Alpha architecture due to the use of software >>> cache-coherency rather than hardware cache-coherency - but we don't have >>> that on ppc!) >>> >>> Sorry - There is no quick resolution here and in a couple of days I will >>> be heading out on vacation for two weeks. >>> >>> David >>> ----- >>> >>>> Best regards, >>>> Goetz. >>>> >>>> -- Other ports: >>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>> not happen on small machines. But I can use PPC_ONLY instead >>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>> >>>> -- MemBarStoreStore after initialization >>>> I agree we should not change it in the ppc port. If you wish, I can >>>> prepare an extra webrev for hotspot-comp. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Okay this is my second attempt at answering this in a reasonable way :) >>>> >>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>> I have to ask David to do correctness evaluation. >>>> >>>> From what I understand what we see here is an attempt to fix an >>>> existing issue with the implementation of volatiles so that the IRIW >>>> problem is addressed. The solution proposed for PPC64 is to make >>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>> load. >>>> >>>> Now if this was purely handled in ppc64 source code then I would be >>>> happy to let them do whatever they like (surely this kills performance >>>> though!). But I do not agree with the changes to the shared code that >>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>> polluting the shared code. My concern is similar to what I said with the >>>> taskQueue changes - these algorithms should be expressed using the >>>> correct OrderAccess operations to guarantee the desired properties >>>> independent of architecture. If such a "barrier" is not needed on a >>>> given architecture then the implementation in OrderAccess should reduce >>>> to a no-op. >>>> >>>> And as Vitaly points out the constructor barriers are not needed under >>>> the JMM. >>>> >>>>> I am fine with suggested changes because you did not change our current >>>>> code for our platforms (please, do not change do_exits() now). >>>>> But may be it should be done using more general query which is set >>>>> depending on platform: >>>>> >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> >>>>> or similar to what we use now: >>>>> >>>>> VM_Version::needs_support_iriw_ordering() >>>> >>>> Every platform has to support IRIW this is simply part of the Java >>>> Memory Model, there should not be any need to call this out explicitly >>>> like this. >>>> >>>> Is there some subtlety of the hardware I am missing here? Are there >>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>> From what I understand our ppc port is also affected. David? >>>> >>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>> >>>> David >>>> ----- >>>> >>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>> >>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>> >>>>> In do_put_xxx() can you combine your changes: >>>>> >>>>> if (is_vol) { >>>>> // See comment in do_get_xxx(). >>>>> #ifndef PPC64 >>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>> #else >>>>> if (is_field) { >>>>> // Add MemBarRelease for constructors which write volatile field >>>>> (PPC64). >>>>> set_wrote_volatile(true); >>>>> } >>>>> #endif >>>>> } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>> the torture test suite: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>> >>>>>> Example: >>>>>> volatile x=0, y=0 >>>>>> __________ __________ __________ __________ >>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>> >>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>> read(y) read(x) >>>>>> >>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>> >>>>>> >>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>> assured by the sync instruction and if it is executed in the threads >>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>> MemBarVolatile happens to be implemented by sync. >>>>>> We fix this in C2 and the cpp interpreter. >>>>>> >>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>> fails on staxf" for taskqueue.hpp. >>>>>> >>>>>> Further this change contains a fix that assures that volatile fields >>>>>> written in constructors are visible before the reference gets >>>>>> published. >>>>>> >>>>>> >>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>> strong. >>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>> What do you think? >>>>>> >>>>>> Please review and test this change. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From goetz.lindenmaier at sap.com Tue Jan 7 01:10:09 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Jan 2014 09:10:09 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52CB9FAE.80800@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52CB9FAE.80800@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8A82A@DEWDFEMB12A.global.corp.sap> Hi David, happy new year for you too! The compiler uses the following operations for volatiles: MemBarRelease --> lwsync Store Load MemBarVolatile --> sync MemBarAcquire --> lwsync With our change we get: MemBarRelease --> lwsync MemBarVolatile --> sync Store Load MemBarAcquire --> lwsync So the lwsync in your example is added by the MemBarRelease before the Store. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 7. Januar 2014 07:33 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi Goetz, Happy New year! :) I'm backing up a step now that I have a better grip on the IRIW issue. On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: > Hi, > > ok, I understand the tests are wrong. It's good this issue is settled. > Thanks Aleksey and Andreas for going into the details of the proof! > > About our change: David, the causality is the other way round. > The change is about IRIW. > 1. To pass IRIW, we must use sync instructions before loads. Okay I see this (though I think we need to kill IRIW as a requirement and I don't think IRIW should form part of any conformance test). > 2. If we do syncs before loads, we don't need to do them after stores. True for the IRIW case but to prevent local reordering of volatile stores don't you still need some form of "storestore" barrier? initially: x = 0; y = 0 Thread 0: Thread 1: x = 1 r1 = x y = 1 r2 = y --------------------------- Should be Forbidden: r1 = 0 ^ r2 = 1 You can add the sync after each read but that doesn't prevent the stores in thread 0 from being locally re-ordered. So I think you still need at least lwsync on the writer side: initially: x = 0; y = 0 Thread 0: Thread 1: x = 1 r1 = x lwsync sync y = 1 r2 = y sync --------------------------- Forbidden: r1 = 0 ^ r2 = 1 David ----- > 3. If we don't do them after stores, we fail the volatile constructor tests. > 4. So finally we added them again at the end of the constructor after stores > to pass the volatile constructor tests. > > We originally passed the constructor tests because the ppc memory order > instructions are not as find-granular as the > operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction > on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the > MemBarVolatile after the store fixes the constructor tests. The proper representation > of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless > anyways. > >> I'm not happy with the ifdef approach but I won't block it. > I'd be happy to add a property > OrderAccess::cpu_is_multiple_copy_atomic() > or the like to guard the customization. I'd like that much better. Or also > OrderAccess::needs_support_iriw_ordering() > VM_Version::needs_support_iriw_ordering() > > > Best regards, > Goetz. > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 28. November 2013 00:34 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > TL;DR version: > > Discussion on the c-i list has now confirmed that a constructor-barrier > for volatiles is not required as part of the JMM specification. It *may* > be required in an implementation that doesn't pre-zero memory to ensure > you can't see uninitialized fields. So the tests for this are invalid > and this part of the patch is not needed in general (ppc64 may need it > due to other factors). > > Re: "multiple copy atomicity" - first thanks for correcting the term :) > Second thanks for the reference to that paper! For reference: > > "The memory system (perhaps involving a hierarchy of buffers and a > complex interconnect) does not guarantee that a write becomes visible to > all other hardware threads at the same time point; these architectures > are not multiple-copy atomic." > > This is the visibility issue that I referred to and affects both ARM and > PPC. But of course it is normally handled by using suitable barriers > after the stores that need to be visible. I think the crux of the > current issue is what you wrote below: > > > The fixes for the constructor issue are only needed because we > > remove the sync instruction from behind stores (parse3.cpp:320) > > and place it before loads. > > I hadn't grasped this part. Obviously if you fail to do the sync after > the store then you have to do something around the loads to get the same > results! I still don't know what lead you to the conclusion that the > only way to fix the IRIW issue was to put the fence before the load - > maybe when I get the chance to read that paper in full it will be clearer. > > So ... the basic problem is that the current structure in the VM has > hard-wired one choice of how to get the right semantics for volatile > variables. You now want to customize that but not all the requisite > hooks are present. It would be better if volatile_load and > volatile_store were factored out so that they could be implemented as > desired per-platform. Alternatively there could be pre- and post- hooks > that could then be customized per platform. Otherwise you need > platform-specific ifdef's to handle it as per your patch. > > I'm not happy with the ifdef approach but I won't block it. I think this > is an area where a lot of clean up is needed in the VM. The barrier > abstractions are a confused mess in my opinion. > > Thanks, > David > ----- > > On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated the webrev to fix the issues mentioned by Vladimir: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >> >> I did not yet add the >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> or >> OrderAccess::cpu_is_multiple_copy_atomic() >> to reduce #defined, as I got no further comment on that. >> >> >> WRT to the validity of the tests and the interpretation of the JMM >> I feel not in the position to contribute substantially. >> >> But we would like to pass the torture test suite as we consider >> this a substantial task in implementing a PPC port. Also we think >> both tests show behavior a programmer would expect. It's bad if >> Java code runs fine on the more common x86 platform, and then >> fails on ppc. This will always first be blamed on the VM. >> >> The fixes for the constructor issue are only needed because we >> remove the sync instruction from behind stores (parse3.cpp:320) >> and place it before loads. Then there is no sync between volatile store >> and publishing the object. So we add it again in this one case >> (volatile store in constructor). >> >> >> @David >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> It may have started a year ago but work on it has hardly been continuous. >> That's not true, we did a lot of investigation and testing on this issue. >> And we came up with a solution we consider the best possible. If you >> have objections, you should at least give the draft of a better solution, >> we would volunteer to implement and test it. >> Similarly, we invested time in fixing the concurrency torture issues. >> >> @David >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >> We learned about this reading "A Tutorial Introduction to the ARM and >> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >> >> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >> instead. Sorry for that. (I also fixed that in the method name above). >> >> Best regards and thanks for all your involvements, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 27. November 2013 12:53 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> -- Volatile in constuctor >>>> AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>> We see them on PPC64. Our test machines have typically 8-32 processors >>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >> >> And see follow ups - the tests are invalid. >> >>> -- IRIW issue >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> >> It may have started a year ago but work on it has hardly been continuous. >> >>>> You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>> solution with the #defines, and that's correct for all, but not nice, I admit. >>> (I don't really know about ARM, though). >>> So if I can write down a nicer solution testing for methods that are evaluated >>> by the C-compiler I'm happy. >>> >>> The problem is not that IRIW is not handled by the JMM, the problem >>> is that >>> store >>> sync >>> does not assure multiple-read-atomicity, >>> only >>> sync >>> load >>> does so on PPC. And you require multiple-read-atomicity to >>> pass that test. >> >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. >> >> Thanks, >> David >> >> The JMM is fine. And >>> store >>> MemBarVolatile >>> is fine on x86, sparc etc. as there exist assembler instructions that >>> do what is required. >>> >>> So if you are off soon, please let's come to a solution that >>> might be improvable in the way it's implemented, but that >>> allows us to implement a correct PPC64 port. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 1:11 PM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>> Hi everybody, >>>> >>>> thanks a lot for the detailed reviews! >>>> I'll try to answer to all in one mail. >>>> >>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>> We don't think it's correct if we omit the barrier after initializing >>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>> and Doug Lea, and they agreed. >>>> Also, concurrency torture tests >>>> LongVolatileTest >>>> AtomicIntegerInitialValueTest >>>> will fail. >>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>> >>> The affects of unsafe publication are always surprising - volatiles do >>> not add anything special here. AFAIK there is nothing in the JMM that >>> requires the constructor barrier - discussions with Doug and Aleksey >>> notwithstanding. AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >>> >>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>> see a way to implement this cheaper. >>>> >>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>> Basically, I agree on this. But you also have to take into account >>>> that due to the different memory ordering instructions on different platforms >>>> just implementing something empty is not sufficient. >>>> An example: >>>> MemBarRelease // means LoadStore, StoreStore barrier >>>> MemBarVolatile // means StoreLoad barrier >>>> If these are consecutively in the code, sparc code looks like this: >>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>> Just doing what is required. >>>> On Power, we get suboptimal code, as there are no comparable, >>>> fine grained operations: >>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>> I need an additional optimization that removes the lwsync. I can not implement >>>> MemBarRelease empty, as it is also used independently. >>>> >>>> Back to the IRIW problem. I think here we have a comparable issue. >>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>> is inefficient on platforms that have multiple-read-atomicity. >>>> >>>> I would propose to guard the code by >>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>> OrderAccess::cpu_is_multiple_read_atomic() >>>> Else, David, how would you propose to implement this platform independent? >>>> (Maybe we can also use above method in taskqueue.hpp.) >>> >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so >>> different?) and I can not take that on face value at the moment. The >>> only reason I can see IRIW not being handled by the JMM requirements for >>> volatile accesses is if there are global visibility issues that are not >>> addressed - but even then I would expect heavy barriers at the store >>> would deal with that, not at the load. (This situation reminds me of the >>> need for read-barriers on Alpha architecture due to the use of software >>> cache-coherency rather than hardware cache-coherency - but we don't have >>> that on ppc!) >>> >>> Sorry - There is no quick resolution here and in a couple of days I will >>> be heading out on vacation for two weeks. >>> >>> David >>> ----- >>> >>>> Best regards, >>>> Goetz. >>>> >>>> -- Other ports: >>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>> not happen on small machines. But I can use PPC_ONLY instead >>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>> >>>> -- MemBarStoreStore after initialization >>>> I agree we should not change it in the ppc port. If you wish, I can >>>> prepare an extra webrev for hotspot-comp. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Okay this is my second attempt at answering this in a reasonable way :) >>>> >>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>> I have to ask David to do correctness evaluation. >>>> >>>> From what I understand what we see here is an attempt to fix an >>>> existing issue with the implementation of volatiles so that the IRIW >>>> problem is addressed. The solution proposed for PPC64 is to make >>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>> load. >>>> >>>> Now if this was purely handled in ppc64 source code then I would be >>>> happy to let them do whatever they like (surely this kills performance >>>> though!). But I do not agree with the changes to the shared code that >>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>> polluting the shared code. My concern is similar to what I said with the >>>> taskQueue changes - these algorithms should be expressed using the >>>> correct OrderAccess operations to guarantee the desired properties >>>> independent of architecture. If such a "barrier" is not needed on a >>>> given architecture then the implementation in OrderAccess should reduce >>>> to a no-op. >>>> >>>> And as Vitaly points out the constructor barriers are not needed under >>>> the JMM. >>>> >>>>> I am fine with suggested changes because you did not change our current >>>>> code for our platforms (please, do not change do_exits() now). >>>>> But may be it should be done using more general query which is set >>>>> depending on platform: >>>>> >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> >>>>> or similar to what we use now: >>>>> >>>>> VM_Version::needs_support_iriw_ordering() >>>> >>>> Every platform has to support IRIW this is simply part of the Java >>>> Memory Model, there should not be any need to call this out explicitly >>>> like this. >>>> >>>> Is there some subtlety of the hardware I am missing here? Are there >>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>> From what I understand our ppc port is also affected. David? >>>> >>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>> >>>> David >>>> ----- >>>> >>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>> >>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>> >>>>> In do_put_xxx() can you combine your changes: >>>>> >>>>> if (is_vol) { >>>>> // See comment in do_get_xxx(). >>>>> #ifndef PPC64 >>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>> #else >>>>> if (is_field) { >>>>> // Add MemBarRelease for constructors which write volatile field >>>>> (PPC64). >>>>> set_wrote_volatile(true); >>>>> } >>>>> #endif >>>>> } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>> the torture test suite: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>> >>>>>> Example: >>>>>> volatile x=0, y=0 >>>>>> __________ __________ __________ __________ >>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>> >>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>> read(y) read(x) >>>>>> >>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>> >>>>>> >>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>> assured by the sync instruction and if it is executed in the threads >>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>> MemBarVolatile happens to be implemented by sync. >>>>>> We fix this in C2 and the cpp interpreter. >>>>>> >>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>> fails on staxf" for taskqueue.hpp. >>>>>> >>>>>> Further this change contains a fix that assures that volatile fields >>>>>> written in constructors are visible before the reference gets >>>>>> published. >>>>>> >>>>>> >>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>> strong. >>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>> What do you think? >>>>>> >>>>>> Please review and test this change. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From david.holmes at oracle.com Tue Jan 7 01:22:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 19:22:06 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8A82A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52CB9FAE.80800@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8A82A@DEWDFEMB12A.global.corp.sap> Message-ID: <52CBC73E.8060501@oracle.com> On 7/01/2014 7:10 PM, Lindenmaier, Goetz wrote: > Hi David, > > happy new year for you too! > > The compiler uses the following operations for volatiles: > > MemBarRelease --> lwsync > Store Load > MemBarVolatile --> sync MemBarAcquire --> lwsync > > With our change we get: > > MemBarRelease --> lwsync MemBarVolatile --> sync > Store Load > MemBarAcquire --> lwsync > > So the lwsync in your example is added by the MemBarRelease before the > Store. Ah I see. Thanks for clarifying. I need to mull on this a little more. David > Best regards, > Goetz. > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 7. Januar 2014 07:33 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > Happy New year! :) > > I'm backing up a step now that I have a better grip on the IRIW issue. > > On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> ok, I understand the tests are wrong. It's good this issue is settled. >> Thanks Aleksey and Andreas for going into the details of the proof! >> >> About our change: David, the causality is the other way round. >> The change is about IRIW. >> 1. To pass IRIW, we must use sync instructions before loads. > > Okay I see this (though I think we need to kill IRIW as a requirement > and I don't think IRIW should form part of any conformance test). > >> 2. If we do syncs before loads, we don't need to do them after stores. > > True for the IRIW case but to prevent local reordering of volatile > stores don't you still need some form of "storestore" barrier? > > initially: x = 0; y = 0 > Thread 0: Thread 1: > x = 1 r1 = x > y = 1 r2 = y > --------------------------- > Should be Forbidden: r1 = 0 ^ r2 = 1 > > You can add the sync after each read but that doesn't prevent the stores > in thread 0 from being locally re-ordered. So I think you still need at > least lwsync on the writer side: > > initially: x = 0; y = 0 > Thread 0: Thread 1: > x = 1 r1 = x > lwsync sync > y = 1 r2 = y > sync > --------------------------- > Forbidden: r1 = 0 ^ r2 = 1 > > David > ----- > >> 3. If we don't do them after stores, we fail the volatile constructor tests. >> 4. So finally we added them again at the end of the constructor after stores >> to pass the volatile constructor tests. >> >> We originally passed the constructor tests because the ppc memory order >> instructions are not as find-granular as the >> operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction >> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the >> MemBarVolatile after the store fixes the constructor tests. The proper representation >> of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless >> anyways. >> >>> I'm not happy with the ifdef approach but I won't block it. >> I'd be happy to add a property >> OrderAccess::cpu_is_multiple_copy_atomic() >> or the like to guard the customization. I'd like that much better. Or also >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 28. November 2013 00:34 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> TL;DR version: >> >> Discussion on the c-i list has now confirmed that a constructor-barrier >> for volatiles is not required as part of the JMM specification. It *may* >> be required in an implementation that doesn't pre-zero memory to ensure >> you can't see uninitialized fields. So the tests for this are invalid >> and this part of the patch is not needed in general (ppc64 may need it >> due to other factors). >> >> Re: "multiple copy atomicity" - first thanks for correcting the term :) >> Second thanks for the reference to that paper! For reference: >> >> "The memory system (perhaps involving a hierarchy of buffers and a >> complex interconnect) does not guarantee that a write becomes visible to >> all other hardware threads at the same time point; these architectures >> are not multiple-copy atomic." >> >> This is the visibility issue that I referred to and affects both ARM and >> PPC. But of course it is normally handled by using suitable barriers >> after the stores that need to be visible. I think the crux of the >> current issue is what you wrote below: >> >> > The fixes for the constructor issue are only needed because we >> > remove the sync instruction from behind stores (parse3.cpp:320) >> > and place it before loads. >> >> I hadn't grasped this part. Obviously if you fail to do the sync after >> the store then you have to do something around the loads to get the same >> results! I still don't know what lead you to the conclusion that the >> only way to fix the IRIW issue was to put the fence before the load - >> maybe when I get the chance to read that paper in full it will be clearer. >> >> So ... the basic problem is that the current structure in the VM has >> hard-wired one choice of how to get the right semantics for volatile >> variables. You now want to customize that but not all the requisite >> hooks are present. It would be better if volatile_load and >> volatile_store were factored out so that they could be implemented as >> desired per-platform. Alternatively there could be pre- and post- hooks >> that could then be customized per platform. Otherwise you need >> platform-specific ifdef's to handle it as per your patch. >> >> I'm not happy with the ifdef approach but I won't block it. I think this >> is an area where a lot of clean up is needed in the VM. The barrier >> abstractions are a confused mess in my opinion. >> >> Thanks, >> David >> ----- >> >> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated the webrev to fix the issues mentioned by Vladimir: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>> >>> I did not yet add the >>> OrderAccess::needs_support_iriw_ordering() >>> VM_Version::needs_support_iriw_ordering() >>> or >>> OrderAccess::cpu_is_multiple_copy_atomic() >>> to reduce #defined, as I got no further comment on that. >>> >>> >>> WRT to the validity of the tests and the interpretation of the JMM >>> I feel not in the position to contribute substantially. >>> >>> But we would like to pass the torture test suite as we consider >>> this a substantial task in implementing a PPC port. Also we think >>> both tests show behavior a programmer would expect. It's bad if >>> Java code runs fine on the more common x86 platform, and then >>> fails on ppc. This will always first be blamed on the VM. >>> >>> The fixes for the constructor issue are only needed because we >>> remove the sync instruction from behind stores (parse3.cpp:320) >>> and place it before loads. Then there is no sync between volatile store >>> and publishing the object. So we add it again in this one case >>> (volatile store in constructor). >>> >>> >>> @David >>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>> and that's being discussed now for almost a year. >>>> It may have started a year ago but work on it has hardly been continuous. >>> That's not true, we did a lot of investigation and testing on this issue. >>> And we came up with a solution we consider the best possible. If you >>> have objections, you should at least give the draft of a better solution, >>> we would volunteer to implement and test it. >>> Similarly, we invested time in fixing the concurrency torture issues. >>> >>> @David >>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>> can't find any reference to it. >>> We learned about this reading "A Tutorial Introduction to the ARM and >>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>> >>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >>> instead. Sorry for that. (I also fixed that in the method name above). >>> >>> Best regards and thanks for all your involvements, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 27. November 2013 12:53 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> -- Volatile in constuctor >>>>> AFAIK we have not seen those tests fail due to a >>>>> missing constructor barrier. >>>> We see them on PPC64. Our test machines have typically 8-32 processors >>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>> >>> And see follow ups - the tests are invalid. >>> >>>> -- IRIW issue >>>>> I can not possibly answer to the necessary level of detail with a few >>>>> moments thought. >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> >>> It may have started a year ago but work on it has hardly been continuous. >>> >>>>> You are implying there is a problem here that will >>>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>>> solution with the #defines, and that's correct for all, but not nice, I admit. >>>> (I don't really know about ARM, though). >>>> So if I can write down a nicer solution testing for methods that are evaluated >>>> by the C-compiler I'm happy. >>>> >>>> The problem is not that IRIW is not handled by the JMM, the problem >>>> is that >>>> store >>>> sync >>>> does not assure multiple-read-atomicity, >>>> only >>>> sync >>>> load >>>> does so on PPC. And you require multiple-read-atomicity to >>>> pass that test. >>> >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >>> >>> Thanks, >>> David >>> >>> The JMM is fine. And >>>> store >>>> MemBarVolatile >>>> is fine on x86, sparc etc. as there exist assembler instructions that >>>> do what is required. >>>> >>>> So if you are off soon, please let's come to a solution that >>>> might be improvable in the way it's implemented, but that >>>> allows us to implement a correct PPC64 port. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>> Hi everybody, >>>>> >>>>> thanks a lot for the detailed reviews! >>>>> I'll try to answer to all in one mail. >>>>> >>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>>> We don't think it's correct if we omit the barrier after initializing >>>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>>> and Doug Lea, and they agreed. >>>>> Also, concurrency torture tests >>>>> LongVolatileTest >>>>> AtomicIntegerInitialValueTest >>>>> will fail. >>>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>>> >>>> The affects of unsafe publication are always surprising - volatiles do >>>> not add anything special here. AFAIK there is nothing in the JMM that >>>> requires the constructor barrier - discussions with Doug and Aleksey >>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>>> >>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>>> see a way to implement this cheaper. >>>>> >>>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>>> Basically, I agree on this. But you also have to take into account >>>>> that due to the different memory ordering instructions on different platforms >>>>> just implementing something empty is not sufficient. >>>>> An example: >>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>> MemBarVolatile // means StoreLoad barrier >>>>> If these are consecutively in the code, sparc code looks like this: >>>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>> Just doing what is required. >>>>> On Power, we get suboptimal code, as there are no comparable, >>>>> fine grained operations: >>>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>>> I need an additional optimization that removes the lwsync. I can not implement >>>>> MemBarRelease empty, as it is also used independently. >>>>> >>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>> >>>>> I would propose to guard the code by >>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>> Else, David, how would you propose to implement this platform independent? >>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>> >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so >>>> different?) and I can not take that on face value at the moment. The >>>> only reason I can see IRIW not being handled by the JMM requirements for >>>> volatile accesses is if there are global visibility issues that are not >>>> addressed - but even then I would expect heavy barriers at the store >>>> would deal with that, not at the load. (This situation reminds me of the >>>> need for read-barriers on Alpha architecture due to the use of software >>>> cache-coherency rather than hardware cache-coherency - but we don't have >>>> that on ppc!) >>>> >>>> Sorry - There is no quick resolution here and in a couple of days I will >>>> be heading out on vacation for two weeks. >>>> >>>> David >>>> ----- >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -- Other ports: >>>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>> >>>>> -- MemBarStoreStore after initialization >>>>> I agree we should not change it in the ppc port. If you wish, I can >>>>> prepare an extra webrev for hotspot-comp. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Okay this is my second attempt at answering this in a reasonable way :) >>>>> >>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>> I have to ask David to do correctness evaluation. >>>>> >>>>> From what I understand what we see here is an attempt to fix an >>>>> existing issue with the implementation of volatiles so that the IRIW >>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>>> load. >>>>> >>>>> Now if this was purely handled in ppc64 source code then I would be >>>>> happy to let them do whatever they like (surely this kills performance >>>>> though!). But I do not agree with the changes to the shared code that >>>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>>> polluting the shared code. My concern is similar to what I said with the >>>>> taskQueue changes - these algorithms should be expressed using the >>>>> correct OrderAccess operations to guarantee the desired properties >>>>> independent of architecture. If such a "barrier" is not needed on a >>>>> given architecture then the implementation in OrderAccess should reduce >>>>> to a no-op. >>>>> >>>>> And as Vitaly points out the constructor barriers are not needed under >>>>> the JMM. >>>>> >>>>>> I am fine with suggested changes because you did not change our current >>>>>> code for our platforms (please, do not change do_exits() now). >>>>>> But may be it should be done using more general query which is set >>>>>> depending on platform: >>>>>> >>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>> >>>>>> or similar to what we use now: >>>>>> >>>>>> VM_Version::needs_support_iriw_ordering() >>>>> >>>>> Every platform has to support IRIW this is simply part of the Java >>>>> Memory Model, there should not be any need to call this out explicitly >>>>> like this. >>>>> >>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>>> From what I understand our ppc port is also affected. David? >>>>> >>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>>> >>>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>> >>>>>> In do_put_xxx() can you combine your changes: >>>>>> >>>>>> if (is_vol) { >>>>>> // See comment in do_get_xxx(). >>>>>> #ifndef PPC64 >>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>> #else >>>>>> if (is_field) { >>>>>> // Add MemBarRelease for constructors which write volatile field >>>>>> (PPC64). >>>>>> set_wrote_volatile(true); >>>>>> } >>>>>> #endif >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>>> the torture test suite: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>> >>>>>>> Example: >>>>>>> volatile x=0, y=0 >>>>>>> __________ __________ __________ __________ >>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>> >>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>> read(y) read(x) >>>>>>> >>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>> >>>>>>> >>>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>>> assured by the sync instruction and if it is executed in the threads >>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>> >>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>> >>>>>>> Further this change contains a fix that assures that volatile fields >>>>>>> written in constructors are visible before the reference gets >>>>>>> published. >>>>>>> >>>>>>> >>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>>> strong. >>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>>> What do you think? >>>>>>> >>>>>>> Please review and test this change. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> From goetz.lindenmaier at sap.com Tue Jan 7 08:49:23 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Jan 2014 16:49:23 +0000 Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap> Hi, This change contains a row of fixes in the ppc and aix coding we collected over the last testing days. Please review this change. http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/ In more detail: Stack overflow issue: code branched to zero. Fix: Generate throw_StackOverflowError stub before generating the native entry. Fix assertion when looking for nmethod in code cache: use unsafe accessor. Also optimize: don't look up the address twice. Fix compressing klass pointers. Implement some missing stuff in the aix os branch. Thanks and best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140107/d685cb63/attachment-0001.html From volker.simonis at gmail.com Tue Jan 7 09:27:37 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 7 Jan 2014 18:27:37 +0100 Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap> Message-ID: Hi, we've forgotten a SAP JVM comment in the code in os_aix.cpp in the method: bool os::find(address addr, outputStream* st) Sorry, that was my fault. It will be removed in the final version. Regards, Volker On Tue, Jan 7, 2014 at 5:49 PM, Lindenmaier, Goetz wrote: > Hi, > > > > This change contains a row of fixes in the ppc and aix coding > > we collected over the last testing days. > > Please review this change. > > http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/ > > > > In more detail: > > > Stack overflow issue: code branched to zero. > Fix: Generate throw_StackOverflowError stub before generating > the native entry. > > Fix assertion when looking for nmethod in code cache: > use unsafe accessor. Also optimize: don't look up the > address twice. > > Fix compressing klass pointers. > > Implement some missing stuff in the aix os branch. > > > > Thanks and best regards, > > Goetz. From vladimir.kozlov at oracle.com Tue Jan 7 09:56:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Jan 2014 09:56:31 -0800 Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap> Message-ID: <52CC3FCF.3070608@oracle.com> Looks fine to me. You can push it since it does not affect shared code. Thanks, Vladimir On 1/7/14 8:49 AM, Lindenmaier, Goetz wrote: > Hi, > > This change contains a row of fixes in the ppc and aix coding > > we collected over the last testing days. > > Please review this change. > > http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/ > > In more detail: > > > Stack overflow issue: code branched to zero. > Fix: Generate throw_StackOverflowError stub before generating > the native entry. > > Fix assertion when looking for nmethod in code cache: > use unsafe accessor. Also optimize: don't look up the > address twice. > > Fix compressing klass pointers. > > Implement some missing stuff in the aix os branch. > > Thanks and best regards, > > Goetz. > From goetz.lindenmaier at sap.com Tue Jan 7 11:21:23 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Jan 2014 19:21:23 +0000 Subject: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding. In-Reply-To: <52CC3FCF.3070608@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8AAEE@DEWDFEMB12A.global.corp.sap> <52CC3FCF.3070608@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8AB45@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for the review, and for testing the other change yesterday. I pushed it, including the fix to the comment. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, January 07, 2014 6:57 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (M): 8031319: PPC64: Some fixes in ppc and aix coding. Looks fine to me. You can push it since it does not affect shared code. Thanks, Vladimir On 1/7/14 8:49 AM, Lindenmaier, Goetz wrote: > Hi, > > This change contains a row of fixes in the ppc and aix coding > > we collected over the last testing days. > > Please review this change. > > http://cr.openjdk.java.net/~goetz/webrevs/8031319-ppcFix/ > > In more detail: > > > Stack overflow issue: code branched to zero. > Fix: Generate throw_StackOverflowError stub before generating > the native entry. > > Fix assertion when looking for nmethod in code cache: > use unsafe accessor. Also optimize: don't look up the > address twice. > > Fix compressing klass pointers. > > Implement some missing stuff in the aix os branch. > > Thanks and best regards, > > Goetz. > From goetz.lindenmaier at sap.com Tue Jan 7 11:16:27 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Tue, 07 Jan 2014 19:16:27 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 8031319: PPC64: Some fixes in ppc and aix coding. Message-ID: <20140107191630.D632B62435@hg.openjdk.java.net> Changeset: c668f307a4c0 Author: goetz Date: 2014-01-07 17:24 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/c668f307a4c0 8031319: PPC64: Some fixes in ppc and aix coding. Reviewed-by: kvn ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/os/aix/vm/os_aix.cpp ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp From goetz.lindenmaier at sap.com Wed Jan 8 06:16:29 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 8 Jan 2014 14:16:29 +0000 Subject: Build of new stage-9 repository Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8AE8B@DEWDFEMB12A.global.corp.sap> Hi, I installed a nightly build for the new stage-9 repository. As expected, the repository builds fine. You can see the results on the known web site: http://cr.openjdk.java.net/~simonis/ppc-aix-port/ More build results will show up tomorrow. I removed the column with the build results of the ppc-aix-port/jdk8 repository from the table, as these are now outdated. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140108/ec9cbada/attachment.html From vladimir.kozlov at oracle.com Wed Jan 8 13:40:32 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 21:40:32 +0000 Subject: hg: ppc-aix-port/stage-9/hotspot: 3 new changesets Message-ID: <20140108214041.A7C9062472@hg.openjdk.java.net> Changeset: 068a5117af73 Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/068a5117af73 Added tag jdk9-b00 for changeset ce2d7e46f3c7 ! .hgtags Changeset: 050a626a8895 Author: iris Date: 2013-12-13 09:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/050a626a8895 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf Changeset: 134e52455808 Author: kvn Date: 2014-01-08 11:24 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/134e52455808 Merge From vladimir.kozlov at oracle.com Wed Jan 8 14:13:36 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 22:13:36 +0000 Subject: hg: ppc-aix-port/stage-9/jaxws: 2 new changesets Message-ID: <20140108221343.A8EA362479@hg.openjdk.java.net> Changeset: 1eeaba183340 Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxws/rev/1eeaba183340 Added tag jdk9-b00 for changeset 32050ab53c8a ! .hgtags Changeset: 9c9fabbcd3d5 Author: iris Date: 2013-12-13 09:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxws/rev/9c9fabbcd3d5 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf From vladimir.kozlov at oracle.com Wed Jan 8 14:13:48 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 22:13:48 +0000 Subject: hg: ppc-aix-port/stage-9/langtools: 2 new changesets Message-ID: <20140108221359.C8C2E6247A@hg.openjdk.java.net> Changeset: 8ec7991f0968 Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/8ec7991f0968 Added tag jdk9-b00 for changeset afe63d41c699 ! .hgtags Changeset: 3edb37befdd0 Author: iris Date: 2013-12-13 09:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/3edb37befdd0 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf From vladimir.kozlov at oracle.com Wed Jan 8 14:14:06 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 22:14:06 +0000 Subject: hg: ppc-aix-port/stage-9/nashorn: 2 new changesets Message-ID: <20140108221409.C7FE26247B@hg.openjdk.java.net> Changeset: 75f66e787d11 Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/nashorn/rev/75f66e787d11 Added tag jdk9-b00 for changeset 32631eed0fad ! .hgtags Changeset: 65347535840f Author: iris Date: 2013-12-13 09:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/nashorn/rev/65347535840f 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf From vladimir.kozlov at oracle.com Wed Jan 8 14:13:25 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 22:13:25 +0000 Subject: hg: ppc-aix-port/stage-9/jaxp: 2 new changesets Message-ID: <20140108221332.5F93162478@hg.openjdk.java.net> Changeset: cec9e799464d Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/cec9e799464d Added tag jdk9-b00 for changeset 4045edd35e8b ! .hgtags Changeset: 9ea0852c341f Author: iris Date: 2013-12-13 09:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/9ea0852c341f 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf From vladimir.kozlov at oracle.com Wed Jan 8 14:13:20 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 22:13:20 +0000 Subject: hg: ppc-aix-port/stage-9/corba: 2 new changesets Message-ID: <20140108221322.9FA6C62476@hg.openjdk.java.net> Changeset: 5eb0c07843fc Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/corba/rev/5eb0c07843fc Added tag jdk9-b00 for changeset a7d3638deb2f ! .hgtags Changeset: 27ab4532fc80 Author: iris Date: 2013-12-13 09:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/corba/rev/27ab4532fc80 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf From vladimir.kozlov at oracle.com Wed Jan 8 14:13:17 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 22:13:17 +0000 Subject: hg: ppc-aix-port/stage-9: 3 new changesets Message-ID: <20140108221318.50A0F62474@hg.openjdk.java.net> Changeset: c2b11b3fa1df Author: iris Date: 2013-12-12 15:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/c2b11b3fa1df Added tag jdk9-b00 for changeset 1e1f86d5d4e2 ! .hgtags Changeset: 4ca37b9541a7 Author: iris Date: 2013-12-13 09:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/4ca37b9541a7 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf Changeset: 06dd913373b4 Author: kvn Date: 2014-01-08 11:20 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/06dd913373b4 Merge From vladimir.kozlov at oracle.com Wed Jan 8 15:17:49 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 23:17:49 +0000 Subject: hg: ppc-aix-port/stage-9/jdk: 3 new changesets Message-ID: <20140108231853.CFD106247C@hg.openjdk.java.net> Changeset: 8d3141b5734b Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/8d3141b5734b Added tag jdk9-b00 for changeset 27b384262cba ! .hgtags Changeset: e554994dd16a Author: iris Date: 2013-12-13 09:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e554994dd16a 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf Changeset: c1e75d17b993 Author: kvn Date: 2014-01-08 11:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/c1e75d17b993 Merge From vladimir.kozlov at oracle.com Wed Jan 8 15:31:47 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 08 Jan 2014 23:31:47 +0000 Subject: hg: ppc-aix-port/stage-9/hotspot: 3 new changesets Message-ID: <20140108233157.830AE6247D@hg.openjdk.java.net> Changeset: ad6695638a35 Author: goetz Date: 2013-12-20 13:51 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/ad6695638a35 8030863: PPC64: (part 220): ConstantTableBase for calls between args and jvms Summary: Add ConstantTableBase node edge after parameters and before jvms. Adapt jvms offsets. Reviewed-by: kvn ! src/cpu/ppc/vm/ppc.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/matcher.cpp Changeset: c3efa8868779 Author: goetz Date: 2014-01-06 11:02 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c3efa8868779 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks Summary: Swap the Projs in the block list so that the new block is added behind the proper node. Reviewed-by: kvn ! src/share/vm/opto/block.cpp Changeset: b858620b0081 Author: goetz Date: 2014-01-07 17:24 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/b858620b0081 8031319: PPC64: Some fixes in ppc and aix coding. Reviewed-by: kvn ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/os/aix/vm/os_aix.cpp ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp From goetz.lindenmaier at sap.com Mon Jan 13 02:40:44 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Jan 2014 10:40:44 +0000 Subject: Red lights on build overview page. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8BC59@DEWDFEMB12A.global.corp.sap> Hi, Somebody may have noticed that the builds on our build result page are not passing: http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html This is not a problem of the port - we have an issue with the disc space for the builds. We are working on this. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140113/f01a1832/attachment.html From volker.simonis at gmail.com Tue Jan 14 00:40:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 09:40:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Message-ID: Hi, could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): http://cr.openjdk.java.net/~simonis/webrevs/8031581/ I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): java/net/Inet6Address/B6558853.java java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) java/nio/channels/Selector/RacyDeregister.java sun/security/krb5/auto/Unreachable.java (only on IPv6) Thank you and best regards, Volker Following a detailed description of the various changes: src/share/native/java/util/zip/zip_util.c src/share/native/sun/management/DiagnosticCommandImpl.c - According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. make/CompileJavaClasses.gmk - Also use PollingWatchService on AIX. make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c - Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. src/solaris/native/sun/nio/ch/PollArrayWrapper.c src/solaris/native/sun/nio/ch/Net.c src/aix/classes/sun/nio/ch/AixPollPort.java src/aix/native/sun/nio/ch/AixPollPort.c src/aix/native/java/net/aix_close.c - On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. src/share/classes/java/nio/file/CopyMoveHelper.java - As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java - Support "compound text" on AIX in the same way like on other Unix platforms. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - Define the correct attach provider for AIX. src/solaris/native/java/net/net_util_md.h src/solaris/native/sun/nio/ch/FileDispatcherImpl.c src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c - AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. - Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). src/solaris/classes/java/lang/UNIXProcess.java.aix - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. src/share/transport/socket/socketTransport.c - On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. - Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. src/solaris/native/java/net/NetworkInterface.c - Set the scope identifier for IPv6 addresses on AIX. src/solaris/native/java/net/net_util_md.c - It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. - Also fixed a comment and removed unused local variables. - Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. src/solaris/native/sun/management/OperatingSystemImpl.c - AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. src/solaris/native/sun/nio/ch/DatagramChannelImpl.c - On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140114/866bb06d/attachment.html From Alan.Bateman at oracle.com Tue Jan 14 01:19:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 09:19:20 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D50118.3080000@oracle.com> On 14/01/2014 08:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration > into ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): I'd like to review this but I won't have time until later in the week. From an initial look then there are a few things are not pretty (the changes to fix the AIX problems with I/O cancellation in particular) and I suspect that some refactoring is going to be required to handle some of this cleanly. A minor comment is that bug synopsis doesn't really communicate what these changes are about. -Alan. From volker.simonis at gmail.com Tue Jan 14 01:56:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 10:56:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: Hi Alan, On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> > > I'd like to review this but I won't have time until later in the week. Thanks, that would be great. > From an initial look then there are a few things are not pretty (the > changes to fix the AIX problems with I/O cancellation in particular) and I > suspect that some refactoring is going to be required to handle some of > this cleanly. I agree, but as I wrote, this change is intended to finally go into both jdk9 and jkd8u and I didn't wanted to do to much refactoring for jdk8u. Once its in and we have a working port I'd be happy to work on refactoring the code but I think this should be done in jdk9 where we have more time and less risks of changing the behaviour on the existing platforms. > A minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > This is the last "bulk change" which address issues in several different areas of the class library. Follow up changes will be more specific with better bug synopsis (I promise :). Regards, Volker > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140114/0f098ab3/attachment-0001.html From david.holmes at oracle.com Tue Jan 14 03:29:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 21:29:48 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D51FAC.8060800@oracle.com> Just a note on this part (I havent looked at the code): > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. Sounds like this should be handled the same way that the other "system constants" are handled - you can either store a platform file in the repo (for cross-compiling) or you generate the class containing the constants at build time. David On 14/01/2014 6:40 PM, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/testresults/testresults.html > ?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This > only fixes a compiler warning on Linux, but on AIX it prevents a VM > crash later on because the return value of |malloc()| will be casted > to |int| which is especially bad if that pointer was bigger than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > * Put the implementation for the native methods of |NativeThread| into > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > * On AIX, the constants used for the polling events (i.e. |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > operating systems. The problem is however, that these constants are > hardcoded as public final static members of various, shared Java > classes. We therefore have to map them from Java to native every > time before calling one of the native poll functions and back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call |Files.getFileAttributeView()| with any > |linkOptions| because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. > > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The |close()| subroutine is blocked until all subroutines which > use the file descriptor return to usr space. For example, when a > thread is calling close and another thread is calling select with > the same file descriptor, the close subroutine does not return until > the select call returns...". To fix this problem, we have to use the > various |NET_| wrappers which are declared in |net_util_md.h| and > defined in |aix_close.c| and we also need some additional wrappers > for |fcntl()|, |read()| and |write()| on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the > best way to go for JDK 8 because it imposes the smallest possible > changes and risks for the existing platforms. I'm ready to change > the code to unconditionally use the wrappers for all platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change it to > something like |IO_|). But again, I'll prefer to keep that as a > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > result in an error (i.e. "EBADF: The FileDescriptor parameter is not > a valid file descriptor open for writing."). To prevent this error > we have to query if the corresponding file descriptor is writeable. > Notice that at that point we can not access the |writable| attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > |close()| system call will block if another thread is at the same > time blocked in a file operation (e.g. 'read()') on the same file > descriptor. We therefore combine the AIX |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > potentially blocking operation on the file descriptor increments a > counter before it is executed and decrements it once it finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last pending > operation has finished. > > > src/share/transport/socket/socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor before > closing it, otherwise the |close()| call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework > doesn't use the same IO wrappers like other class library components > so we can not easily use the |NET_| abstractions from |aix_close.c| > here. > * Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down itself > because one thread will always be blocked in the |close()| call on > one of the communication sockets. > > > src/solaris/native/java/net/NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/net_util_md.c > > * It turns out that we do not always have to replace |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same approach > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = prevTime;| which > should read |prevTime = newTime;|. Otherwise |prevTime| will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/management/OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query the real > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a > socket with the address family set to |AF_UNSPEC|. > > From goetz.lindenmaier at sap.com Tue Jan 14 05:52:04 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Jan 2014 13:52:04 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> Hi, I updated this webrev. I detected a small flaw I made when editing this version. The #endif in line 322, parse3.cpp was in the wrong line. I also based the webrev on the latest version of the stage repo. http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 20. Dezember 2013 13:47 To: David Holmes Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi David, > So we can at least undo #4 now we have established those tests were not > required to pass. We would prefer if we could keep this in. We want to avoid that it's blamed on the VM if java programs are failing on PPC after they worked on x86. To clearly mark it as overfulfilling the spec I would guard it by a flag as proposed. But if you insist I will remove it. Also, this part is not that performance relevant. > A compile-time guard (ifdef) would be better than a runtime one I think I added a compile-time guard in this new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC) but this way I only have to change the ppc platform. Best regards, Goetz P.S.: I will also be available over the Christmas period. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 20. Dezember 2013 05:58 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Sorry for the delay, it takes a while to catch up after two weeks vacation :) Next vacation (ie next two weeks) I'll continue to check emails. On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: > Hi, > > ok, I understand the tests are wrong. It's good this issue is settled. > Thanks Aleksey and Andreas for going into the details of the proof! > > About our change: David, the causality is the other way round. > The change is about IRIW. > 1. To pass IRIW, we must use sync instructions before loads. This is the part I still have some question marks over as the implications are not nice for performance on non-TSO platforms. But I'm no further along in processing that paper I'm afraid. > 2. If we do syncs before loads, we don't need to do them after stores. > 3. If we don't do them after stores, we fail the volatile constructor tests. > 4. So finally we added them again at the end of the constructor after stores > to pass the volatile constructor tests. So we can at least undo #4 now we have established those tests were not required to pass. > We originally passed the constructor tests because the ppc memory order > instructions are not as find-granular as the > operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction > on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the > MemBarVolatile after the store fixes the constructor tests. The proper representation > of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless > anyways. > >> I'm not happy with the ifdef approach but I won't block it. > I'd be happy to add a property > OrderAccess::cpu_is_multiple_copy_atomic() A compile-time guard (ifdef) would be better than a runtime one I think - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic based not architecture based) as that will allows for turning this on/off for any architecture for testing purposes. Thanks, David > or the like to guard the customization. I'd like that much better. Or also > OrderAccess::needs_support_iriw_ordering() > VM_Version::needs_support_iriw_ordering() > > > Best regards, > Goetz. > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 28. November 2013 00:34 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > TL;DR version: > > Discussion on the c-i list has now confirmed that a constructor-barrier > for volatiles is not required as part of the JMM specification. It *may* > be required in an implementation that doesn't pre-zero memory to ensure > you can't see uninitialized fields. So the tests for this are invalid > and this part of the patch is not needed in general (ppc64 may need it > due to other factors). > > Re: "multiple copy atomicity" - first thanks for correcting the term :) > Second thanks for the reference to that paper! For reference: > > "The memory system (perhaps involving a hierarchy of buffers and a > complex interconnect) does not guarantee that a write becomes visible to > all other hardware threads at the same time point; these architectures > are not multiple-copy atomic." > > This is the visibility issue that I referred to and affects both ARM and > PPC. But of course it is normally handled by using suitable barriers > after the stores that need to be visible. I think the crux of the > current issue is what you wrote below: > > > The fixes for the constructor issue are only needed because we > > remove the sync instruction from behind stores (parse3.cpp:320) > > and place it before loads. > > I hadn't grasped this part. Obviously if you fail to do the sync after > the store then you have to do something around the loads to get the same > results! I still don't know what lead you to the conclusion that the > only way to fix the IRIW issue was to put the fence before the load - > maybe when I get the chance to read that paper in full it will be clearer. > > So ... the basic problem is that the current structure in the VM has > hard-wired one choice of how to get the right semantics for volatile > variables. You now want to customize that but not all the requisite > hooks are present. It would be better if volatile_load and > volatile_store were factored out so that they could be implemented as > desired per-platform. Alternatively there could be pre- and post- hooks > that could then be customized per platform. Otherwise you need > platform-specific ifdef's to handle it as per your patch. > > I'm not happy with the ifdef approach but I won't block it. I think this > is an area where a lot of clean up is needed in the VM. The barrier > abstractions are a confused mess in my opinion. > > Thanks, > David > ----- > > On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated the webrev to fix the issues mentioned by Vladimir: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >> >> I did not yet add the >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> or >> OrderAccess::cpu_is_multiple_copy_atomic() >> to reduce #defined, as I got no further comment on that. >> >> >> WRT to the validity of the tests and the interpretation of the JMM >> I feel not in the position to contribute substantially. >> >> But we would like to pass the torture test suite as we consider >> this a substantial task in implementing a PPC port. Also we think >> both tests show behavior a programmer would expect. It's bad if >> Java code runs fine on the more common x86 platform, and then >> fails on ppc. This will always first be blamed on the VM. >> >> The fixes for the constructor issue are only needed because we >> remove the sync instruction from behind stores (parse3.cpp:320) >> and place it before loads. Then there is no sync between volatile store >> and publishing the object. So we add it again in this one case >> (volatile store in constructor). >> >> >> @David >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> It may have started a year ago but work on it has hardly been continuous. >> That's not true, we did a lot of investigation and testing on this issue. >> And we came up with a solution we consider the best possible. If you >> have objections, you should at least give the draft of a better solution, >> we would volunteer to implement and test it. >> Similarly, we invested time in fixing the concurrency torture issues. >> >> @David >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >> We learned about this reading "A Tutorial Introduction to the ARM and >> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >> >> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >> instead. Sorry for that. (I also fixed that in the method name above). >> >> Best regards and thanks for all your involvements, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 27. November 2013 12:53 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> -- Volatile in constuctor >>>> AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>> We see them on PPC64. Our test machines have typically 8-32 processors >>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >> >> And see follow ups - the tests are invalid. >> >>> -- IRIW issue >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> >> It may have started a year ago but work on it has hardly been continuous. >> >>>> You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>> solution with the #defines, and that's correct for all, but not nice, I admit. >>> (I don't really know about ARM, though). >>> So if I can write down a nicer solution testing for methods that are evaluated >>> by the C-compiler I'm happy. >>> >>> The problem is not that IRIW is not handled by the JMM, the problem >>> is that >>> store >>> sync >>> does not assure multiple-read-atomicity, >>> only >>> sync >>> load >>> does so on PPC. And you require multiple-read-atomicity to >>> pass that test. >> >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. >> >> Thanks, >> David >> >> The JMM is fine. And >>> store >>> MemBarVolatile >>> is fine on x86, sparc etc. as there exist assembler instructions that >>> do what is required. >>> >>> So if you are off soon, please let's come to a solution that >>> might be improvable in the way it's implemented, but that >>> allows us to implement a correct PPC64 port. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 1:11 PM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>> Hi everybody, >>>> >>>> thanks a lot for the detailed reviews! >>>> I'll try to answer to all in one mail. >>>> >>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>> We don't think it's correct if we omit the barrier after initializing >>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>> and Doug Lea, and they agreed. >>>> Also, concurrency torture tests >>>> LongVolatileTest >>>> AtomicIntegerInitialValueTest >>>> will fail. >>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>> >>> The affects of unsafe publication are always surprising - volatiles do >>> not add anything special here. AFAIK there is nothing in the JMM that >>> requires the constructor barrier - discussions with Doug and Aleksey >>> notwithstanding. AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >>> >>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>> see a way to implement this cheaper. >>>> >>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>> Basically, I agree on this. But you also have to take into account >>>> that due to the different memory ordering instructions on different platforms >>>> just implementing something empty is not sufficient. >>>> An example: >>>> MemBarRelease // means LoadStore, StoreStore barrier >>>> MemBarVolatile // means StoreLoad barrier >>>> If these are consecutively in the code, sparc code looks like this: >>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>> Just doing what is required. >>>> On Power, we get suboptimal code, as there are no comparable, >>>> fine grained operations: >>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>> I need an additional optimization that removes the lwsync. I can not implement >>>> MemBarRelease empty, as it is also used independently. >>>> >>>> Back to the IRIW problem. I think here we have a comparable issue. >>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>> is inefficient on platforms that have multiple-read-atomicity. >>>> >>>> I would propose to guard the code by >>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>> OrderAccess::cpu_is_multiple_read_atomic() >>>> Else, David, how would you propose to implement this platform independent? >>>> (Maybe we can also use above method in taskqueue.hpp.) >>> >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so >>> different?) and I can not take that on face value at the moment. The >>> only reason I can see IRIW not being handled by the JMM requirements for >>> volatile accesses is if there are global visibility issues that are not >>> addressed - but even then I would expect heavy barriers at the store >>> would deal with that, not at the load. (This situation reminds me of the >>> need for read-barriers on Alpha architecture due to the use of software >>> cache-coherency rather than hardware cache-coherency - but we don't have >>> that on ppc!) >>> >>> Sorry - There is no quick resolution here and in a couple of days I will >>> be heading out on vacation for two weeks. >>> >>> David >>> ----- >>> >>>> Best regards, >>>> Goetz. >>>> >>>> -- Other ports: >>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>> not happen on small machines. But I can use PPC_ONLY instead >>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>> >>>> -- MemBarStoreStore after initialization >>>> I agree we should not change it in the ppc port. If you wish, I can >>>> prepare an extra webrev for hotspot-comp. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Okay this is my second attempt at answering this in a reasonable way :) >>>> >>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>> I have to ask David to do correctness evaluation. >>>> >>>> From what I understand what we see here is an attempt to fix an >>>> existing issue with the implementation of volatiles so that the IRIW >>>> problem is addressed. The solution proposed for PPC64 is to make >>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>> load. >>>> >>>> Now if this was purely handled in ppc64 source code then I would be >>>> happy to let them do whatever they like (surely this kills performance >>>> though!). But I do not agree with the changes to the shared code that >>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>> polluting the shared code. My concern is similar to what I said with the >>>> taskQueue changes - these algorithms should be expressed using the >>>> correct OrderAccess operations to guarantee the desired properties >>>> independent of architecture. If such a "barrier" is not needed on a >>>> given architecture then the implementation in OrderAccess should reduce >>>> to a no-op. >>>> >>>> And as Vitaly points out the constructor barriers are not needed under >>>> the JMM. >>>> >>>>> I am fine with suggested changes because you did not change our current >>>>> code for our platforms (please, do not change do_exits() now). >>>>> But may be it should be done using more general query which is set >>>>> depending on platform: >>>>> >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> >>>>> or similar to what we use now: >>>>> >>>>> VM_Version::needs_support_iriw_ordering() >>>> >>>> Every platform has to support IRIW this is simply part of the Java >>>> Memory Model, there should not be any need to call this out explicitly >>>> like this. >>>> >>>> Is there some subtlety of the hardware I am missing here? Are there >>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>> From what I understand our ppc port is also affected. David? >>>> >>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>> >>>> David >>>> ----- >>>> >>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>> >>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>> >>>>> In do_put_xxx() can you combine your changes: >>>>> >>>>> if (is_vol) { >>>>> // See comment in do_get_xxx(). >>>>> #ifndef PPC64 >>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>> #else >>>>> if (is_field) { >>>>> // Add MemBarRelease for constructors which write volatile field >>>>> (PPC64). >>>>> set_wrote_volatile(true); >>>>> } >>>>> #endif >>>>> } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>> the torture test suite: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>> >>>>>> Example: >>>>>> volatile x=0, y=0 >>>>>> __________ __________ __________ __________ >>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>> >>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>> read(y) read(x) >>>>>> >>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>> >>>>>> >>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>> assured by the sync instruction and if it is executed in the threads >>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>> MemBarVolatile happens to be implemented by sync. >>>>>> We fix this in C2 and the cpp interpreter. >>>>>> >>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>> fails on staxf" for taskqueue.hpp. >>>>>> >>>>>> Further this change contains a fix that assures that volatile fields >>>>>> written in constructors are visible before the reference gets >>>>>> published. >>>>>> >>>>>> >>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>> strong. >>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>> What do you think? >>>>>> >>>>>> Please review and test this change. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From volker.simonis at gmail.com Tue Jan 14 06:10:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 15:10:27 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D51FAC.8060800@oracle.com> References: <52D51FAC.8060800@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 12:29 PM, David Holmes wrote: > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. >> > > Sounds like this should be handled the same way that the other "system > constants" are handled - you can either store a platform file in the repo > (for cross-compiling) or you generate the class containing the constants at > build time. > > Hi David, thanks for your comments. That sound like a good idea but I'm not sure if it would make sense to duplicate the following files: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: src/solaris/classes/sun/nio/ch/Port.java because of this. Do you have a concrete example where Java-classes are being generated with different constants in the class library build? Both solutions would result in different class files on Aix and other Unix variants. What do you think about assigning the concrete values depending on 'os.name' in the static initializers of the corresponding classes? I think that shouldn't introduce too much overhead and I could get rid of all the ugly conversion code. Regards, Volker > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but >> the following 7 jtreg regression tests on AIX (compared to the >> Linux/x86_64 baseline from >> www.java.net/download/jdk8/testresults/testresults.html >> ?): >> >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> * According to ISO C it is perfectly legal for malloc to return zero >> >> if called with a zero argument. Fix various places where malloc can >> potentially correctly return zero because it was called with a zero >> argument. >> * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This >> >> only fixes a compiler warning on Linux, but on AIX it prevents a VM >> crash later on because the return value of |malloc()| will be casted >> to |int| which is especially bad if that pointer was bigger than >> 32-bit. >> >> >> make/CompileJavaClasses.gmk >> >> * Also use |PollingWatchService| on AIX. >> >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> * Put the implementation for the native methods of |NativeThread| into >> >> |AixNativeThread.c| on AIX. >> >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> * On AIX, the constants used for the polling events (i.e. |POLLIN|, >> |POLLOUT|, ...) are defined to different values than on other >> >> operating systems. The problem is however, that these constants are >> hardcoded as public final static members of various, shared Java >> classes. We therefore have to map them from Java to native every >> time before calling one of the native poll functions and back to >> Java after the call on AIX in order to get the right semantics. >> >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> * As discussed on the core-libs mailing list (see >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013- >> December/024119.html) >> it is not necessary to call |Files.getFileAttributeView()| with any >> |linkOptions| because at that place we've already checked that the >> target file can not be a symbolic link. This change makes the >> implementation more robust on platforms which support symbolic links >> but do not support the |O_NOFOLLOW| flag to the |open| system call. >> It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. >> >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> * Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com. >> sun.tools.attach.spi.AttachProvider >> >> * Define the correct attach provider for AIX. >> >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> * AIX needs a workaround for I/O cancellation (see: >> >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index. >> jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The |close()| subroutine is blocked until all subroutines which >> use the file descriptor return to usr space. For example, when a >> thread is calling close and another thread is calling select with >> the same file descriptor, the close subroutine does not return until >> the select call returns...". To fix this problem, we have to use the >> various |NET_| wrappers which are declared in |net_util_md.h| and >> defined in |aix_close.c| and we also need some additional wrappers >> for |fcntl()|, |read()| and |write()| on AIX. >> >> While the current solution isn't really nice because it introduces >> some more AIX-specifc sections in shared code, I think it is the >> best way to go for JDK 8 because it imposes the smallest possible >> changes and risks for the existing platforms. I'm ready to change >> the code to unconditionally use the wrappers for all platforms and >> implement the wrappers empty on platforms which don't need any >> wrapping. I think it would also be nice to clean up the names (e.g. >> |NET_Read()| is currently a wrapper for |recv()| and the |NET_| >> prefix is probably not appropriate any more so maybe change it to >> something like |IO_|). But again, I'll prefer to keep that as a >> >> follow up change for JDK9. >> * Calling |fsync()| on a "read-only" file descriptor on AIX will >> >> result in an error (i.e. "EBADF: The FileDescriptor parameter is not >> a valid file descriptor open for writing."). To prevent this error >> we have to query if the corresponding file descriptor is writeable. >> Notice that at that point we can not access the |writable| attribute >> of the corresponding file channel so we have to use |fcntl()|. >> >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> * On AIX the implementation is especially tricky, because the >> >> |close()| system call will block if another thread is at the same >> time blocked in a file operation (e.g. 'read()') on the same file >> descriptor. We therefore combine the AIX |ProcessPipeInputStream| >> implemenatation with the |DeferredCloseInputStream| approach used on >> Solaris (see |UNIXProcess.java.solaris|). This means that every >> >> potentially blocking operation on the file descriptor increments a >> counter before it is executed and decrements it once it finishes. >> The 'close()' operation will only be executed if there are no >> pending operations. Otherwise it is deferred after the last pending >> operation has finished. >> >> >> src/share/transport/socket/socketTransport.c >> >> * On AIX we have to call |shutdown()| on a socket descriptor before >> >> closing it, otherwise the |close()| call may be blocked. This is the >> same problem as described before. Unfortunately the JDI framework >> doesn't use the same IO wrappers like other class library components >> so we can not easily use the |NET_| abstractions from |aix_close.c| >> here. >> * Without this small change all JDI regression tests will fail on AIX >> >> because of the way how the tests act as a "debugger" which launches >> another VM (the "debugge") which connects itself back to the >> debugger. In this scenario the "debugge" can not shut down itself >> because one thread will always be blocked in the |close()| call on >> one of the communication sockets. >> >> >> src/solaris/native/java/net/NetworkInterface.c >> >> * Set the scope identifier for IPv6 addresses on AIX. >> >> >> src/solaris/native/java/net/net_util_md.c >> >> * It turns out that we do not always have to replace |SO_REUSEADDR| on >> AIX by |SO_REUSEPORT|. Instead we can simply use the same approach >> >> like BSD and only use |SO_REUSEPORT| additionally, if several >> datagram sockets try to bind to the same port. >> * Also fixed a comment and removed unused local variables. >> * Fixed the obviously inverted assignment |newTime = prevTime;| which >> >> should read |prevTime = newTime;|. Otherwise |prevTime| will never >> change and the timeout will be potential reached too fast. >> >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> * AIX does not understand |/proc/self| so we have to query the real >> >> process ID to access the proc file system. >> >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a >> >> socket with the address family set to |AF_UNSPEC|. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140114/e6f3ed73/attachment.html From volker.simonis at gmail.com Tue Jan 14 08:57:48 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 17:57:48 +0100 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX Message-ID: Hi, could you please review the following change: http://cr.openjdk.java.net/~simonis/webrevs/8028537/ which, together with the changes from "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and "8031134 : PPC64: implement printing on AIX" enables our our port to pass all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): java/net/Inet6Address/B6558853.java java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) java/nio/channels/Selector/RacyDeregister.java sun/security/krb5/auto/Unreachable.java (only on IPv6) The change is only big in the amount of files it touches but rather small in the amount of actual code changes so I flagged it with S/L. Most changes simply add AIX as a known platform to the OS detection sections of the various tests. The are either of the form: case "$OS" in - SunOS | Linux | Darwin ) + SunOS | Linux | Darwin | AIX ) PATHSEP=":" or: isSolaris=true ;; + AIX ) + OS="AIX" + isAIX=true + ;; Windows* ) OS="Windows" The following explanations only mention test with changes different to the ones above: test/ProblemList.txt - Added three tests which currently don't work on AIX. test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java - This test calls JFrame.setDefaultCloseOperation() which is not allowed under the security manager which is active if the test are running in agentvm mode. So better always run this test in othervm mode. test/com/sun/jdi/PrivateTransportTest.sh - On AIX, we have to use LIBPATH instead of LD_LIBRARY_PATH. test/com/sun/nio/sctp/SctpChannel/Util.java test/com/sun/nio/sctp/SctpMultiChannel/Util.java test/com/sun/nio/sctp/SctpServerChannel/Util.java - On AIX, we currently haven't implemented SCTP but we nevertheless compile the shared SCTP classes into the runtime class library. This way the AIX JDK can at least compile SCTP applications altough it can not run them. To support this scenario, the runtime check for the availability of SCTP has to be extended to catch UnsatisfiedLinkError and NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first time when the class SctpChannelImpl will be loaded because it cannot load the its native support library in the static initialisation section. On the next load attempt of the class, a NoClassDefFoundError will be thrown because of the previously failed initialisation. test/java/net/DatagramSocket/Send12k.java - AIX throws an IOException: Message too long if the message is too long. DatagramSocket.send() is specified to throw an IOException so better don't be too specific in the catch clause. test/java/nio/file/Files/SBC.java - AIX actually supports symbolic links, but it does not support NOFOLLOW_LINKS, or more exactly the O_NOFOLLOW flag to the open() system call which is tested here. test/java/nio/file/Files/walkFileTree/find.sh - On AIX find -follow may core dump on recursive links without '-L' (see http://www-01.ibm.com/support/docview.wss?uid=isg1IV28143). test/java/util/logging/AnonLoggerWeakRefLeak.sh test/java/util/logging/LoggerWeakRefLeak.sh - Only treat missing jmap options as warnings and not as errors. test/sun/rmi/rmic/newrmic/equivalence/batch.sh - On AIX the diff utility doesn't detect binary files and thus outputs the full diff of different class files which makes the test fail. Because the generated class files aren?t used or checked anyway we can completely omit the generation of class files by always using the -nowrite option. - Also reformatted the command lines to make the differences more apparent. test/tools/launcher/ExecutionEnvironment.java - On AIX, we have to use LIBPATH instead of LD_LIBRARY_PATH. - AIX does not support the -rpath linker options so the launchers have to prepend the jdk library path to LIBPATH. test/tools/launcher/Settings.java - On PPC64 we need a bigger stack size. Thank you and best regards, Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140114/0c97a9bc/attachment-0001.html From Alan.Bateman at oracle.com Tue Jan 14 11:13:25 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 19:13:25 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: Message-ID: <52D58C55.6070004@oracle.com> On 14/01/2014 16:57, Volker Simonis wrote: > : > > test/com/sun/nio/sctp/SctpChannel/Util.java > test/com/sun/nio/sctp/SctpMultiChannel/Util.java > test/com/sun/nio/sctp/SctpServerChannel/Util.java > > - On AIX, we currently haven't implemented SCTP but we nevertheless > compile the shared SCTP classes into the runtime class library. This way > the AIX JDK can at least compile SCTP applications altough it can not run > them. To support this scenario, the runtime check for the availability of > SCTP has to be extended to catch UnsatisfiedLinkError and > NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first time > when the class SctpChannelImpl will be loaded because it cannot load the > its native support library in the static initialisation section. On the > next load attempt of the class, a NoClassDefFoundError will be thrown > because of the previously failed initialisation. > OS X has the same issue and the solution used there are stub implementations that just throw UOE. Details in jdk/src/macosx/classes/sun/nio/ch/sctp and that maybe that would work for AIX too. -Alan. From david.holmes at oracle.com Tue Jan 14 16:55:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2014 10:55:28 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> Message-ID: <52D5DC80.1040003@oracle.com> Hi Goetz, Sorry for the delay in getting back to this. The general changes to the volatile barriers to support IRIW are okay. The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more specifically it is not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of the commentary excessive, particularly for shared code. In particular the IRIW example in parse3.cpp - it seems a strange place to give the explanation and I don't think we need it to that level of detail. Seems to me that is present is globalDefinitions_ppc.hpp is quite adequate. The changes related to volatile writes in the constructor, as discussed are not required by the Java Memory Model. If you want to keep these then I think they should all be guarded with PPC64 because it is not related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the PPC64 porters. Thanks, David On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: > Hi, > > I updated this webrev. I detected a small flaw I made when editing this version. > The #endif in line 322, parse3.cpp was in the wrong line. > I also based the webrev on the latest version of the stage repo. > http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ > > Best regards, > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 20. Dezember 2013 13:47 > To: David Holmes > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi David, > >> So we can at least undo #4 now we have established those tests were not >> required to pass. > We would prefer if we could keep this in. We want to avoid that it's > blamed on the VM if java programs are failing on PPC after they worked > on x86. To clearly mark it as overfulfilling the spec I would guard it by > a flag as proposed. But if you insist I will remove it. Also, this part is > not that performance relevant. > >> A compile-time guard (ifdef) would be better than a runtime one I think > I added a compile-time guard in this new webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ > I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces > several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC) > but this way I only have to change the ppc platform. > > Best regards, > Goetz > > P.S.: I will also be available over the Christmas period. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 20. Dezember 2013 05:58 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Sorry for the delay, it takes a while to catch up after two weeks > vacation :) Next vacation (ie next two weeks) I'll continue to check emails. > > On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> ok, I understand the tests are wrong. It's good this issue is settled. >> Thanks Aleksey and Andreas for going into the details of the proof! >> >> About our change: David, the causality is the other way round. >> The change is about IRIW. >> 1. To pass IRIW, we must use sync instructions before loads. > > This is the part I still have some question marks over as the > implications are not nice for performance on non-TSO platforms. But I'm > no further along in processing that paper I'm afraid. > >> 2. If we do syncs before loads, we don't need to do them after stores. >> 3. If we don't do them after stores, we fail the volatile constructor tests. >> 4. So finally we added them again at the end of the constructor after stores >> to pass the volatile constructor tests. > > So we can at least undo #4 now we have established those tests were not > required to pass. > >> We originally passed the constructor tests because the ppc memory order >> instructions are not as find-granular as the >> operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction >> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the >> MemBarVolatile after the store fixes the constructor tests. The proper representation >> of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless >> anyways. >> >>> I'm not happy with the ifdef approach but I won't block it. >> I'd be happy to add a property >> OrderAccess::cpu_is_multiple_copy_atomic() > > A compile-time guard (ifdef) would be better than a runtime one I think > - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic > based not architecture based) as that will allows for turning this > on/off for any architecture for testing purposes. > > Thanks, > David > >> or the like to guard the customization. I'd like that much better. Or also >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 28. November 2013 00:34 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> TL;DR version: >> >> Discussion on the c-i list has now confirmed that a constructor-barrier >> for volatiles is not required as part of the JMM specification. It *may* >> be required in an implementation that doesn't pre-zero memory to ensure >> you can't see uninitialized fields. So the tests for this are invalid >> and this part of the patch is not needed in general (ppc64 may need it >> due to other factors). >> >> Re: "multiple copy atomicity" - first thanks for correcting the term :) >> Second thanks for the reference to that paper! For reference: >> >> "The memory system (perhaps involving a hierarchy of buffers and a >> complex interconnect) does not guarantee that a write becomes visible to >> all other hardware threads at the same time point; these architectures >> are not multiple-copy atomic." >> >> This is the visibility issue that I referred to and affects both ARM and >> PPC. But of course it is normally handled by using suitable barriers >> after the stores that need to be visible. I think the crux of the >> current issue is what you wrote below: >> >> > The fixes for the constructor issue are only needed because we >> > remove the sync instruction from behind stores (parse3.cpp:320) >> > and place it before loads. >> >> I hadn't grasped this part. Obviously if you fail to do the sync after >> the store then you have to do something around the loads to get the same >> results! I still don't know what lead you to the conclusion that the >> only way to fix the IRIW issue was to put the fence before the load - >> maybe when I get the chance to read that paper in full it will be clearer. >> >> So ... the basic problem is that the current structure in the VM has >> hard-wired one choice of how to get the right semantics for volatile >> variables. You now want to customize that but not all the requisite >> hooks are present. It would be better if volatile_load and >> volatile_store were factored out so that they could be implemented as >> desired per-platform. Alternatively there could be pre- and post- hooks >> that could then be customized per platform. Otherwise you need >> platform-specific ifdef's to handle it as per your patch. >> >> I'm not happy with the ifdef approach but I won't block it. I think this >> is an area where a lot of clean up is needed in the VM. The barrier >> abstractions are a confused mess in my opinion. >> >> Thanks, >> David >> ----- >> >> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated the webrev to fix the issues mentioned by Vladimir: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>> >>> I did not yet add the >>> OrderAccess::needs_support_iriw_ordering() >>> VM_Version::needs_support_iriw_ordering() >>> or >>> OrderAccess::cpu_is_multiple_copy_atomic() >>> to reduce #defined, as I got no further comment on that. >>> >>> >>> WRT to the validity of the tests and the interpretation of the JMM >>> I feel not in the position to contribute substantially. >>> >>> But we would like to pass the torture test suite as we consider >>> this a substantial task in implementing a PPC port. Also we think >>> both tests show behavior a programmer would expect. It's bad if >>> Java code runs fine on the more common x86 platform, and then >>> fails on ppc. This will always first be blamed on the VM. >>> >>> The fixes for the constructor issue are only needed because we >>> remove the sync instruction from behind stores (parse3.cpp:320) >>> and place it before loads. Then there is no sync between volatile store >>> and publishing the object. So we add it again in this one case >>> (volatile store in constructor). >>> >>> >>> @David >>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>> and that's being discussed now for almost a year. >>>> It may have started a year ago but work on it has hardly been continuous. >>> That's not true, we did a lot of investigation and testing on this issue. >>> And we came up with a solution we consider the best possible. If you >>> have objections, you should at least give the draft of a better solution, >>> we would volunteer to implement and test it. >>> Similarly, we invested time in fixing the concurrency torture issues. >>> >>> @David >>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>> can't find any reference to it. >>> We learned about this reading "A Tutorial Introduction to the ARM and >>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>> >>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >>> instead. Sorry for that. (I also fixed that in the method name above). >>> >>> Best regards and thanks for all your involvements, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 27. November 2013 12:53 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> -- Volatile in constuctor >>>>> AFAIK we have not seen those tests fail due to a >>>>> missing constructor barrier. >>>> We see them on PPC64. Our test machines have typically 8-32 processors >>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>> >>> And see follow ups - the tests are invalid. >>> >>>> -- IRIW issue >>>>> I can not possibly answer to the necessary level of detail with a few >>>>> moments thought. >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> >>> It may have started a year ago but work on it has hardly been continuous. >>> >>>>> You are implying there is a problem here that will >>>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>>> solution with the #defines, and that's correct for all, but not nice, I admit. >>>> (I don't really know about ARM, though). >>>> So if I can write down a nicer solution testing for methods that are evaluated >>>> by the C-compiler I'm happy. >>>> >>>> The problem is not that IRIW is not handled by the JMM, the problem >>>> is that >>>> store >>>> sync >>>> does not assure multiple-read-atomicity, >>>> only >>>> sync >>>> load >>>> does so on PPC. And you require multiple-read-atomicity to >>>> pass that test. >>> >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >>> >>> Thanks, >>> David >>> >>> The JMM is fine. And >>>> store >>>> MemBarVolatile >>>> is fine on x86, sparc etc. as there exist assembler instructions that >>>> do what is required. >>>> >>>> So if you are off soon, please let's come to a solution that >>>> might be improvable in the way it's implemented, but that >>>> allows us to implement a correct PPC64 port. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>> Hi everybody, >>>>> >>>>> thanks a lot for the detailed reviews! >>>>> I'll try to answer to all in one mail. >>>>> >>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>>> We don't think it's correct if we omit the barrier after initializing >>>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>>> and Doug Lea, and they agreed. >>>>> Also, concurrency torture tests >>>>> LongVolatileTest >>>>> AtomicIntegerInitialValueTest >>>>> will fail. >>>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>>> >>>> The affects of unsafe publication are always surprising - volatiles do >>>> not add anything special here. AFAIK there is nothing in the JMM that >>>> requires the constructor barrier - discussions with Doug and Aleksey >>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>>> >>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>>> see a way to implement this cheaper. >>>>> >>>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>>> Basically, I agree on this. But you also have to take into account >>>>> that due to the different memory ordering instructions on different platforms >>>>> just implementing something empty is not sufficient. >>>>> An example: >>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>> MemBarVolatile // means StoreLoad barrier >>>>> If these are consecutively in the code, sparc code looks like this: >>>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>> Just doing what is required. >>>>> On Power, we get suboptimal code, as there are no comparable, >>>>> fine grained operations: >>>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>>> I need an additional optimization that removes the lwsync. I can not implement >>>>> MemBarRelease empty, as it is also used independently. >>>>> >>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>> >>>>> I would propose to guard the code by >>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>> Else, David, how would you propose to implement this platform independent? >>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>> >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so >>>> different?) and I can not take that on face value at the moment. The >>>> only reason I can see IRIW not being handled by the JMM requirements for >>>> volatile accesses is if there are global visibility issues that are not >>>> addressed - but even then I would expect heavy barriers at the store >>>> would deal with that, not at the load. (This situation reminds me of the >>>> need for read-barriers on Alpha architecture due to the use of software >>>> cache-coherency rather than hardware cache-coherency - but we don't have >>>> that on ppc!) >>>> >>>> Sorry - There is no quick resolution here and in a couple of days I will >>>> be heading out on vacation for two weeks. >>>> >>>> David >>>> ----- >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -- Other ports: >>>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>> >>>>> -- MemBarStoreStore after initialization >>>>> I agree we should not change it in the ppc port. If you wish, I can >>>>> prepare an extra webrev for hotspot-comp. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Okay this is my second attempt at answering this in a reasonable way :) >>>>> >>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>> I have to ask David to do correctness evaluation. >>>>> >>>>> From what I understand what we see here is an attempt to fix an >>>>> existing issue with the implementation of volatiles so that the IRIW >>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>>> load. >>>>> >>>>> Now if this was purely handled in ppc64 source code then I would be >>>>> happy to let them do whatever they like (surely this kills performance >>>>> though!). But I do not agree with the changes to the shared code that >>>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>>> polluting the shared code. My concern is similar to what I said with the >>>>> taskQueue changes - these algorithms should be expressed using the >>>>> correct OrderAccess operations to guarantee the desired properties >>>>> independent of architecture. If such a "barrier" is not needed on a >>>>> given architecture then the implementation in OrderAccess should reduce >>>>> to a no-op. >>>>> >>>>> And as Vitaly points out the constructor barriers are not needed under >>>>> the JMM. >>>>> >>>>>> I am fine with suggested changes because you did not change our current >>>>>> code for our platforms (please, do not change do_exits() now). >>>>>> But may be it should be done using more general query which is set >>>>>> depending on platform: >>>>>> >>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>> >>>>>> or similar to what we use now: >>>>>> >>>>>> VM_Version::needs_support_iriw_ordering() >>>>> >>>>> Every platform has to support IRIW this is simply part of the Java >>>>> Memory Model, there should not be any need to call this out explicitly >>>>> like this. >>>>> >>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>>> From what I understand our ppc port is also affected. David? >>>>> >>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>>> >>>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>> >>>>>> In do_put_xxx() can you combine your changes: >>>>>> >>>>>> if (is_vol) { >>>>>> // See comment in do_get_xxx(). >>>>>> #ifndef PPC64 >>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>> #else >>>>>> if (is_field) { >>>>>> // Add MemBarRelease for constructors which write volatile field >>>>>> (PPC64). >>>>>> set_wrote_volatile(true); >>>>>> } >>>>>> #endif >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>>> the torture test suite: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>> >>>>>>> Example: >>>>>>> volatile x=0, y=0 >>>>>>> __________ __________ __________ __________ >>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>> >>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>> read(y) read(x) >>>>>>> >>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>> >>>>>>> >>>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>>> assured by the sync instruction and if it is executed in the threads >>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>> >>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>> >>>>>>> Further this change contains a fix that assures that volatile fields >>>>>>> written in constructors are visible before the reference gets >>>>>>> published. >>>>>>> >>>>>>> >>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>>> strong. >>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>>> What do you think? >>>>>>> >>>>>>> Please review and test this change. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> From david.holmes at oracle.com Tue Jan 14 22:24:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2014 16:24:32 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> Message-ID: <52D629A0.4080806@oracle.com> On 15/01/2014 12:10 AM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 12:29 PM, David Holmes > wrote: > > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other > operating systems. The problem is however, that these constants > are hardcoded as public final static members of various, shared > Java classes. > > > Sounds like this should be handled the same way that the other > "system constants" are handled - you can either store a platform > file in the repo (for cross-compiling) or you generate the class > containing the constants at build time. > > > Hi David, > > thanks for your comments. That sound like a good idea but I'm not sure > if it would make sense to duplicate the following files: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: > src/solaris/classes/sun/nio/ch/Port.java > > because of this. Do you have a concrete example where Java-classes are > being generated with different constants in the class library build? There are two files generated: UnixConstants.java (or SolarisConstants.java) for general I/O type values SocketOptionRegistry.java for socket options. See jdk/make/gensrc/GensrcMisc.gmk. > Both solutions would result in different class files on Aix and other > Unix variants. What do you think about assigning the concrete values > depending on 'os.name ' in the static initializers of > the corresponding classes? I think that shouldn't introduce too much > overhead and I could get rid of all the ugly conversion code. I'm not a fan of runtime checks of this kind though if it is only a very samll number of values it might be okay. Another option would be to make those classes into "templates" as done with Version.java.template and substitute the right values at build time. But I'll let Alan and net-dev folk come back with their preferred technique for this. Cheers, David > > Regards, > Volker > > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for > integration into > ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): > > http://cr.openjdk.java.net/~__simonis/webrevs/8031581/ > > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: > PPC64: > Updated jdk/test scripts to understand the AIX os and > environment" and > "8031134 : PPC64: implement printing on AIX") our port passes > all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/__testresults/testresults.html > > >?): > > > java/net/Inet6Address/__B6558853.java > java/nio/channels/__AsynchronousChannelGroup/__Basic.java > (sporadically) > java/nio/channels/__AsynchronousChannelGroup/__GroupOfOne.java > java/nio/channels/__AsynchronousChannelGroup/__Unbounded.java > (sporadically) > java/nio/channels/Selector/__RacyDeregister.java > sun/security/krb5/auto/__Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/__zip/zip_util.c > src/share/native/sun/__management/__DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to > return zero > > if called with a zero argument. Fix various places where > malloc can > potentially correctly return zero because it was called > with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. > This > > only fixes a compiler warning on Linux, but on AIX it > prevents a VM > crash later on because the return value of |malloc()| will > be casted > to |int| which is especially bad if that pointer was bigger > than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/__AixNativeThread.c > > * Put the implementation for the native methods of > |NativeThread| into > > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/__PollArrayWrapper.c > src/solaris/native/sun/nio/ch/__Net.c > src/aix/classes/sun/nio/ch/__AixPollPort.java > src/aix/native/sun/nio/ch/__AixPollPort.c > src/aix/native/java/net/aix___close.c > > * On AIX, the constants used for the polling events (i.e. > |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > > operating systems. The problem is however, that these > constants are > hardcoded as public final static members of various, shared > Java > classes. We therefore have to map them from Java to native > every > time before calling one of the native poll functions and > back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/__file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > > http://mail.openjdk.java.net/__pipermail/core-libs-dev/2013-__December/024119.html > ) > it is not necessary to call |Files.getFileAttributeView()| > with any > |linkOptions| because at that place we've already checked > that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support > symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| > system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test > on AIX. > > > src/share/classes/sun/nio/cs/__ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on > other Unix > platforms. > > > > src/share/classes/sun/tools/__attach/META-INF/services/com.__sun.tools.attach.spi.__AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/__net_util_md.h > src/solaris/native/sun/nio/ch/__FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/__ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > > http://publib.boulder.ibm.com/__infocenter/pseries/v5r3/index.__jsp?topic=/com.ibm.aix.__basetechref/doc/basetrf1/__close.htm > ). > "..The |close()| subroutine is blocked until all > subroutines which > use the file descriptor return to usr space. For example, > when a > thread is calling close and another thread is calling > select with > the same file descriptor, the close subroutine does not > return until > the select call returns...". To fix this problem, we have > to use the > various |NET_| wrappers which are declared in > |net_util_md.h| and > defined in |aix_close.c| and we also need some additional > wrappers > for |fcntl()|, |read()| and |write()| on AIX. > > While the current solution isn't really nice because it > introduces > some more AIX-specifc sections in shared code, I think it > is the > best way to go for JDK 8 because it imposes the smallest > possible > changes and risks for the existing platforms. I'm ready to > change > the code to unconditionally use the wrappers for all > platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the > names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change > it to > something like |IO_|). But again, I'll prefer to keep that as a > > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > > result in an error (i.e. "EBADF: The FileDescriptor > parameter is not > a valid file descriptor open for writing."). To prevent > this error > we have to query if the corresponding file descriptor is > writeable. > Notice that at that point we can not access the |writable| > attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/__UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > > |close()| system call will block if another thread is at > the same > time blocked in a file operation (e.g. 'read()') on the > same file > descriptor. We therefore combine the AIX > |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| > approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > > potentially blocking operation on the file descriptor > increments a > counter before it is executed and decrements it once it > finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last > pending > operation has finished. > > > src/share/transport/socket/__socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor > before > > closing it, otherwise the |close()| call may be blocked. > This is the > same problem as described before. Unfortunately the JDI > framework > doesn't use the same IO wrappers like other class library > components > so we can not easily use the |NET_| abstractions from > |aix_close.c| > here. > * Without this small change all JDI regression tests will > fail on AIX > > because of the way how the tests act as a "debugger" which > launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down > itself > because one thread will always be blocked in the |close()| > call on > one of the communication sockets. > > > src/solaris/native/java/net/__NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/__net_util_md.c > > * It turns out that we do not always have to replace > |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same > approach > > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = > prevTime;| which > > should read |prevTime = newTime;|. Otherwise |prevTime| > will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/__management/__OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query > the real > > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/__DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if > called on a > > socket with the address family set to |AF_UNSPEC|. > > > From staffan.larsen at oracle.com Wed Jan 15 00:57:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 09:57:31 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Volker, I?ve look at the following files: src/share/native/sun/management/DiagnosticCommandImpl.c: nit: ?legel? -> ?legal? (two times) In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. src/solaris/native/sun/management/OperatingSystemImpl.c No comments. src/share/transport/socket/socketTransport.c No comments. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider No comments. Thanks, /Staffan On 14 jan 2014, at 09:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. > Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. > make/CompileJavaClasses.gmk > > Also use PollingWatchService on AIX. > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. > src/share/classes/java/nio/file/CopyMoveHelper.java > > As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > Support "compound text" on AIX in the same way like on other Unix platforms. > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > Define the correct attach provider for AIX. > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). > src/solaris/classes/java/lang/UNIXProcess.java.aix > > On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. > src/share/transport/socket/socketTransport.c > > On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. > Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. > src/solaris/native/java/net/NetworkInterface.c > > Set the scope identifier for IPv6 addresses on AIX. > src/solaris/native/java/net/net_util_md.c > > It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. > Also fixed a comment and removed unused local variables. > Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. > src/solaris/native/sun/management/OperatingSystemImpl.c > > AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/691071b6/attachment.html From Alan.Bateman at oracle.com Wed Jan 15 01:03:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jan 2014 09:03:17 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D629A0.4080806@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> Message-ID: <52D64ED5.4020409@oracle.com> On 15/01/2014 06:24, David Holmes wrote: > > I'm not a fan of runtime checks of this kind though if it is only a > very samll number of values it might be okay. > > Another option would be to make those classes into "templates" as done > with Version.java.template and substitute the right values at build time. > > But I'll let Alan and net-dev folk come back with their preferred > technique for this. > I plan to spend time on Volker's webrev later in the week (just too busy with other things right now). For the translation issue then it's an oversight in the original implementation, it just hasn't come up before (to my knowledge anyway). The simplest solution here maybe to to just move them to sun.net.ch.Net and have them initialized to their native value. In general then I'm not too concerned about that one, it's the changes to support async close on AIX that are leaping out at me. -Alan From volker.simonis at gmail.com Wed Jan 15 03:05:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 12:05:14 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D64ED5.4020409@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > On 15/01/2014 06:24, David Holmes wrote: > >> >> I'm not a fan of runtime checks of this kind though if it is only a very >> samll number of values it might be okay. >> >> Another option would be to make those classes into "templates" as done >> with Version.java.template and substitute the right values at build time. >> >> But I'll let Alan and net-dev folk come back with their preferred >> technique for this. >> >> I plan to spend time on Volker's webrev later in the week (just too busy > with other things right now). For the translation issue then it's an > oversight in the original implementation, it just hasn't come up before (to > my knowledge anyway). The simplest solution here maybe to to just move them > to sun.net.ch.Net and have them initialized to their native value. Do you mean sun.nio.ch.Net right? Do you propose to completely remove the definitions of the POLL constants from: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java src/solaris/classes/sun/nio/ch/Port.java and replace all their usages by Net.POLL* ? > In general then I'm not too concerned about that one, it's the changes to > support async close on AIX that are leaping out at me. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/d0df4591/attachment-0001.html From goetz.lindenmaier at sap.com Wed Jan 15 07:28:15 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 Jan 2014 15:28:15 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D5DC80.1040003@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> Hi David, I updated the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ - I removed the IRIW example in parse3.cpp - I adapted the comments not to point to that comment, and to reflect the new flagging. Also I mention that we support the volatile constructor issue, but that it's not standard. - I protected issuing the barrier for the constructor by PPC64. I also think it's better to separate these this way. Thanks for your comments! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Mittwoch, 15. Januar 2014 01:55 To: Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi Goetz, Sorry for the delay in getting back to this. The general changes to the volatile barriers to support IRIW are okay. The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more specifically it is not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of the commentary excessive, particularly for shared code. In particular the IRIW example in parse3.cpp - it seems a strange place to give the explanation and I don't think we need it to that level of detail. Seems to me that is present is globalDefinitions_ppc.hpp is quite adequate. The changes related to volatile writes in the constructor, as discussed are not required by the Java Memory Model. If you want to keep these then I think they should all be guarded with PPC64 because it is not related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the PPC64 porters. Thanks, David On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: > Hi, > > I updated this webrev. I detected a small flaw I made when editing this version. > The #endif in line 322, parse3.cpp was in the wrong line. > I also based the webrev on the latest version of the stage repo. > http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ > > Best regards, > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 20. Dezember 2013 13:47 > To: David Holmes > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi David, > >> So we can at least undo #4 now we have established those tests were not >> required to pass. > We would prefer if we could keep this in. We want to avoid that it's > blamed on the VM if java programs are failing on PPC after they worked > on x86. To clearly mark it as overfulfilling the spec I would guard it by > a flag as proposed. But if you insist I will remove it. Also, this part is > not that performance relevant. > >> A compile-time guard (ifdef) would be better than a runtime one I think > I added a compile-time guard in this new webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ > I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces > several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC) > but this way I only have to change the ppc platform. > > Best regards, > Goetz > > P.S.: I will also be available over the Christmas period. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 20. Dezember 2013 05:58 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Sorry for the delay, it takes a while to catch up after two weeks > vacation :) Next vacation (ie next two weeks) I'll continue to check emails. > > On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> ok, I understand the tests are wrong. It's good this issue is settled. >> Thanks Aleksey and Andreas for going into the details of the proof! >> >> About our change: David, the causality is the other way round. >> The change is about IRIW. >> 1. To pass IRIW, we must use sync instructions before loads. > > This is the part I still have some question marks over as the > implications are not nice for performance on non-TSO platforms. But I'm > no further along in processing that paper I'm afraid. > >> 2. If we do syncs before loads, we don't need to do them after stores. >> 3. If we don't do them after stores, we fail the volatile constructor tests. >> 4. So finally we added them again at the end of the constructor after stores >> to pass the volatile constructor tests. > > So we can at least undo #4 now we have established those tests were not > required to pass. > >> We originally passed the constructor tests because the ppc memory order >> instructions are not as find-granular as the >> operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction >> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the >> MemBarVolatile after the store fixes the constructor tests. The proper representation >> of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless >> anyways. >> >>> I'm not happy with the ifdef approach but I won't block it. >> I'd be happy to add a property >> OrderAccess::cpu_is_multiple_copy_atomic() > > A compile-time guard (ifdef) would be better than a runtime one I think > - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic > based not architecture based) as that will allows for turning this > on/off for any architecture for testing purposes. > > Thanks, > David > >> or the like to guard the customization. I'd like that much better. Or also >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 28. November 2013 00:34 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> TL;DR version: >> >> Discussion on the c-i list has now confirmed that a constructor-barrier >> for volatiles is not required as part of the JMM specification. It *may* >> be required in an implementation that doesn't pre-zero memory to ensure >> you can't see uninitialized fields. So the tests for this are invalid >> and this part of the patch is not needed in general (ppc64 may need it >> due to other factors). >> >> Re: "multiple copy atomicity" - first thanks for correcting the term :) >> Second thanks for the reference to that paper! For reference: >> >> "The memory system (perhaps involving a hierarchy of buffers and a >> complex interconnect) does not guarantee that a write becomes visible to >> all other hardware threads at the same time point; these architectures >> are not multiple-copy atomic." >> >> This is the visibility issue that I referred to and affects both ARM and >> PPC. But of course it is normally handled by using suitable barriers >> after the stores that need to be visible. I think the crux of the >> current issue is what you wrote below: >> >> > The fixes for the constructor issue are only needed because we >> > remove the sync instruction from behind stores (parse3.cpp:320) >> > and place it before loads. >> >> I hadn't grasped this part. Obviously if you fail to do the sync after >> the store then you have to do something around the loads to get the same >> results! I still don't know what lead you to the conclusion that the >> only way to fix the IRIW issue was to put the fence before the load - >> maybe when I get the chance to read that paper in full it will be clearer. >> >> So ... the basic problem is that the current structure in the VM has >> hard-wired one choice of how to get the right semantics for volatile >> variables. You now want to customize that but not all the requisite >> hooks are present. It would be better if volatile_load and >> volatile_store were factored out so that they could be implemented as >> desired per-platform. Alternatively there could be pre- and post- hooks >> that could then be customized per platform. Otherwise you need >> platform-specific ifdef's to handle it as per your patch. >> >> I'm not happy with the ifdef approach but I won't block it. I think this >> is an area where a lot of clean up is needed in the VM. The barrier >> abstractions are a confused mess in my opinion. >> >> Thanks, >> David >> ----- >> >> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated the webrev to fix the issues mentioned by Vladimir: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>> >>> I did not yet add the >>> OrderAccess::needs_support_iriw_ordering() >>> VM_Version::needs_support_iriw_ordering() >>> or >>> OrderAccess::cpu_is_multiple_copy_atomic() >>> to reduce #defined, as I got no further comment on that. >>> >>> >>> WRT to the validity of the tests and the interpretation of the JMM >>> I feel not in the position to contribute substantially. >>> >>> But we would like to pass the torture test suite as we consider >>> this a substantial task in implementing a PPC port. Also we think >>> both tests show behavior a programmer would expect. It's bad if >>> Java code runs fine on the more common x86 platform, and then >>> fails on ppc. This will always first be blamed on the VM. >>> >>> The fixes for the constructor issue are only needed because we >>> remove the sync instruction from behind stores (parse3.cpp:320) >>> and place it before loads. Then there is no sync between volatile store >>> and publishing the object. So we add it again in this one case >>> (volatile store in constructor). >>> >>> >>> @David >>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>> and that's being discussed now for almost a year. >>>> It may have started a year ago but work on it has hardly been continuous. >>> That's not true, we did a lot of investigation and testing on this issue. >>> And we came up with a solution we consider the best possible. If you >>> have objections, you should at least give the draft of a better solution, >>> we would volunteer to implement and test it. >>> Similarly, we invested time in fixing the concurrency torture issues. >>> >>> @David >>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>> can't find any reference to it. >>> We learned about this reading "A Tutorial Introduction to the ARM and >>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>> >>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >>> instead. Sorry for that. (I also fixed that in the method name above). >>> >>> Best regards and thanks for all your involvements, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 27. November 2013 12:53 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> -- Volatile in constuctor >>>>> AFAIK we have not seen those tests fail due to a >>>>> missing constructor barrier. >>>> We see them on PPC64. Our test machines have typically 8-32 processors >>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>> >>> And see follow ups - the tests are invalid. >>> >>>> -- IRIW issue >>>>> I can not possibly answer to the necessary level of detail with a few >>>>> moments thought. >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> >>> It may have started a year ago but work on it has hardly been continuous. >>> >>>>> You are implying there is a problem here that will >>>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>>> solution with the #defines, and that's correct for all, but not nice, I admit. >>>> (I don't really know about ARM, though). >>>> So if I can write down a nicer solution testing for methods that are evaluated >>>> by the C-compiler I'm happy. >>>> >>>> The problem is not that IRIW is not handled by the JMM, the problem >>>> is that >>>> store >>>> sync >>>> does not assure multiple-read-atomicity, >>>> only >>>> sync >>>> load >>>> does so on PPC. And you require multiple-read-atomicity to >>>> pass that test. >>> >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >>> >>> Thanks, >>> David >>> >>> The JMM is fine. And >>>> store >>>> MemBarVolatile >>>> is fine on x86, sparc etc. as there exist assembler instructions that >>>> do what is required. >>>> >>>> So if you are off soon, please let's come to a solution that >>>> might be improvable in the way it's implemented, but that >>>> allows us to implement a correct PPC64 port. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>> Hi everybody, >>>>> >>>>> thanks a lot for the detailed reviews! >>>>> I'll try to answer to all in one mail. >>>>> >>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>>> We don't think it's correct if we omit the barrier after initializing >>>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>>> and Doug Lea, and they agreed. >>>>> Also, concurrency torture tests >>>>> LongVolatileTest >>>>> AtomicIntegerInitialValueTest >>>>> will fail. >>>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>>> >>>> The affects of unsafe publication are always surprising - volatiles do >>>> not add anything special here. AFAIK there is nothing in the JMM that >>>> requires the constructor barrier - discussions with Doug and Aleksey >>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>>> >>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>>> see a way to implement this cheaper. >>>>> >>>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>>> Basically, I agree on this. But you also have to take into account >>>>> that due to the different memory ordering instructions on different platforms >>>>> just implementing something empty is not sufficient. >>>>> An example: >>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>> MemBarVolatile // means StoreLoad barrier >>>>> If these are consecutively in the code, sparc code looks like this: >>>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>> Just doing what is required. >>>>> On Power, we get suboptimal code, as there are no comparable, >>>>> fine grained operations: >>>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>>> I need an additional optimization that removes the lwsync. I can not implement >>>>> MemBarRelease empty, as it is also used independently. >>>>> >>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>> >>>>> I would propose to guard the code by >>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>> Else, David, how would you propose to implement this platform independent? >>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>> >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so >>>> different?) and I can not take that on face value at the moment. The >>>> only reason I can see IRIW not being handled by the JMM requirements for >>>> volatile accesses is if there are global visibility issues that are not >>>> addressed - but even then I would expect heavy barriers at the store >>>> would deal with that, not at the load. (This situation reminds me of the >>>> need for read-barriers on Alpha architecture due to the use of software >>>> cache-coherency rather than hardware cache-coherency - but we don't have >>>> that on ppc!) >>>> >>>> Sorry - There is no quick resolution here and in a couple of days I will >>>> be heading out on vacation for two weeks. >>>> >>>> David >>>> ----- >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -- Other ports: >>>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>> >>>>> -- MemBarStoreStore after initialization >>>>> I agree we should not change it in the ppc port. If you wish, I can >>>>> prepare an extra webrev for hotspot-comp. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Okay this is my second attempt at answering this in a reasonable way :) >>>>> >>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>> I have to ask David to do correctness evaluation. >>>>> >>>>> From what I understand what we see here is an attempt to fix an >>>>> existing issue with the implementation of volatiles so that the IRIW >>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>>> load. >>>>> >>>>> Now if this was purely handled in ppc64 source code then I would be >>>>> happy to let them do whatever they like (surely this kills performance >>>>> though!). But I do not agree with the changes to the shared code that >>>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>>> polluting the shared code. My concern is similar to what I said with the >>>>> taskQueue changes - these algorithms should be expressed using the >>>>> correct OrderAccess operations to guarantee the desired properties >>>>> independent of architecture. If such a "barrier" is not needed on a >>>>> given architecture then the implementation in OrderAccess should reduce >>>>> to a no-op. >>>>> >>>>> And as Vitaly points out the constructor barriers are not needed under >>>>> the JMM. >>>>> >>>>>> I am fine with suggested changes because you did not change our current >>>>>> code for our platforms (please, do not change do_exits() now). >>>>>> But may be it should be done using more general query which is set >>>>>> depending on platform: >>>>>> >>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>> >>>>>> or similar to what we use now: >>>>>> >>>>>> VM_Version::needs_support_iriw_ordering() >>>>> >>>>> Every platform has to support IRIW this is simply part of the Java >>>>> Memory Model, there should not be any need to call this out explicitly >>>>> like this. >>>>> >>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>>> From what I understand our ppc port is also affected. David? >>>>> >>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>>> >>>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>> >>>>>> In do_put_xxx() can you combine your changes: >>>>>> >>>>>> if (is_vol) { >>>>>> // See comment in do_get_xxx(). >>>>>> #ifndef PPC64 >>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>> #else >>>>>> if (is_field) { >>>>>> // Add MemBarRelease for constructors which write volatile field >>>>>> (PPC64). >>>>>> set_wrote_volatile(true); >>>>>> } >>>>>> #endif >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>>> the torture test suite: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>> >>>>>>> Example: >>>>>>> volatile x=0, y=0 >>>>>>> __________ __________ __________ __________ >>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>> >>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>> read(y) read(x) >>>>>>> >>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>> >>>>>>> >>>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>>> assured by the sync instruction and if it is executed in the threads >>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>> >>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>> >>>>>>> Further this change contains a fix that assures that volatile fields >>>>>>> written in constructors are visible before the reference gets >>>>>>> published. >>>>>>> >>>>>>> >>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>>> strong. >>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>>> What do you think? >>>>>>> >>>>>>> Please review and test this change. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> From volker.simonis at gmail.com Wed Jan 15 08:34:58 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 17:34:58 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Hi Staffan, thanks for the review. Please find my comments inline: On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > you allow dcmd_info_array to become NULL, > then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you > need to check that. > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: dcmdInfoCls = (*env)->FindClass(env, "sun/management/DiagnosticCommandInfo"); num_commands = (*env)->GetArrayLength(env, commands); if (num_commands = 0) { result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); if (result == NULL) { JNU_ThrowOutOfMemoryError(env, 0); } else { return result; } } dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); That seems easier and saves me from handling the exception. What do you think? src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but the > following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > - According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only > fixes a compiler warning on Linux, but on AIX it prevents a VM crash later > on because the return value of malloc() will be casted to int which is > especially bad if that pointer was bigger than 32-bit. > > make/CompileJavaClasses.gmk > > - Also use PollingWatchService on AIX. > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > - Put the implementation for the native methods of NativeThread into > AixNativeThread.c on AIX. > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > - On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other operating > systems. The problem is however, that these constants are hardcoded as > public final static members of various, shared Java classes. We therefore > have to map them from Java to native every time before calling one of the > native poll functions and back to Java after the call on AIX in order to > get the right semantics. > > src/share/classes/java/nio/file/CopyMoveHelper.java > > - As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call Files.getFileAttributeView() with any > linkOptions because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links but do > not support the O_NOFOLLOW flag to the open system call. It also makes > the JDK pass the demo/zipfs/basic.sh test on AIX. > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > - Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > - Define the correct attach provider for AIX. > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > - AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The close() subroutine is blocked until all subroutines which use > the file descriptor return to usr space. For example, when a thread is > calling close and another thread is calling select with the same file > descriptor, the close subroutine does not return until the select call > returns...". To fix this problem, we have to use the various NET_wrappers which are declared in > net_util_md.h and defined in aix_close.c and we also need some > additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the best way > to go for JDK 8 because it imposes the smallest possible changes and risks > for the existing platforms. I'm ready to change the code to unconditionally > use the wrappers for all platforms and implement the wrappers empty on > platforms which don't need any wrapping. I think it would also be nice to > clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the > NET_ prefix is probably not appropriate any more so maybe change it to > something like IO_). But again, I'll prefer to keep that as a follow > up change for JDK9. > - Calling fsync() on a "read-only" file descriptor on AIX will result > in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > descriptor open for writing."). To prevent this error we have to query if > the corresponding file descriptor is writeable. Notice that at that point > we can not access the writable attribute of the corresponding file > channel so we have to use fcntl(). > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a > file operation (e.g. 'read()') on the same file descriptor. We therefore > combine the AIX ProcessPipeInputStream implemenatation with the > DeferredCloseInputStream approach used on Solaris (see > UNIXProcess.java.solaris). This means that every potentially blocking > operation on the file descriptor increments a counter before it is executed > and decrements it once it finishes. The 'close()' operation will only be > executed if there are no pending operations. Otherwise it is deferred after > the last pending operation has finished. > > src/share/transport/socket/socketTransport.c > > - On AIX we have to call shutdown() on a socket descriptor before > closing it, otherwise the close() call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework doesn't > use the same IO wrappers like other class library components so we can not > easily use the NET_ abstractions from aix_close.c here. > - Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches another > VM (the "debugge") which connects itself back to the debugger. In this > scenario the "debugge" can not shut down itself because one thread will > always be blocked in the close() call on one of the communication > sockets. > > src/solaris/native/java/net/NetworkInterface.c > > - Set the scope identifier for IPv6 addresses on AIX. > > src/solaris/native/java/net/net_util_md.c > > - It turns out that we do not always have to replace SO_REUSEADDR on > AIX by SO_REUSEPORT. Instead we can simply use the same approach like > BSD and only use SO_REUSEPORT additionally, if several datagram > sockets try to bind to the same port. > - Also fixed a comment and removed unused local variables. > - Fixed the obviously inverted assignment newTime = prevTime; which > should read prevTime = newTime;. Otherwise prevTime will never change > and the timeout will be potential reached too fast. > > src/solaris/native/sun/management/OperatingSystemImpl.c > > - AIX does not understand /proc/self so we have to query the real > process ID to access the proc file system. > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > - On AIX, connect() may legally return EAFNOSUPPORT if called on a > socket with the address family set to AF_UNSPEC. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/6f1cd9ba/attachment-0001.html From volker.simonis at gmail.com Wed Jan 15 08:42:47 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 17:42:47 +0100 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: <52D58C55.6070004@oracle.com> References: <52D58C55.6070004@oracle.com> Message-ID: Hi Alan, thanks for the suggestion. That's fine for me. I've copied the empty SCTP stubs from the macosx to the aix directory as well and updated the make file accordingly (in the patch for "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests"). Therefore, the changes to the three tests: test/com/sun/nio/sctp/SctpChannel/Util.java test/com/sun/nio/sctp/SctpMultiChannel/Util.java test/com/sun/nio/sctp/SctpServerChannel/Util.java can be considered obsolete. Regards, Volker On Tue, Jan 14, 2014 at 8:13 PM, Alan Bateman wrote: > On 14/01/2014 16:57, Volker Simonis wrote: > >> : >> >> test/com/sun/nio/sctp/SctpChannel/Util.java >> test/com/sun/nio/sctp/SctpMultiChannel/Util.java >> test/com/sun/nio/sctp/SctpServerChannel/Util.java >> >> - On AIX, we currently haven't implemented SCTP but we nevertheless >> >> compile the shared SCTP classes into the runtime class library. This >> way >> the AIX JDK can at least compile SCTP applications altough it can not >> run >> them. To support this scenario, the runtime check for the >> availability of >> SCTP has to be extended to catch UnsatisfiedLinkError and >> NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first >> time >> when the class SctpChannelImpl will be loaded because it cannot load >> the >> its native support library in the static initialisation section. On >> the >> next load attempt of the class, a NoClassDefFoundError will be thrown >> because of the previously failed initialisation. >> >> OS X has the same issue and the solution used there are stub > implementations that just throw UOE. Details in jdk/src/macosx/classes/sun/nio/ch/sctp > and that maybe that would work for AIX too. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/332896b9/attachment.html From volker.simonis at gmail.com Wed Jan 15 09:27:01 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:27:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I?ve look at the following files: >> >> src/share/native/sun/management/DiagnosticCommandImpl.c: >> nit: ?legel? -> ?legal? (two times) >> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >> you allow dcmd_info_array to become NULL, then >> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >> check that. > > > Good catch. I actually had problems with malloc returning NULL in > 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be > perfectly fine to return a zero length array. So what about the following > solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); Sorry, of course I wanted to say "if (num_commands == 0)" here! > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > >> src/solaris/native/sun/management/OperatingSystemImpl.c >> No comments. >> >> src/share/transport/socket/socketTransport.c >> No comments. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> No comments. >> >> >> Thanks, >> /Staffan >> >> >> >> On 14 jan 2014, at 09:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but the >> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if >> called with a zero argument. Fix various places where malloc can potentially >> correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >> compiler warning on Linux, but on AIX it prevents a VM crash later on >> because the return value of malloc() will be casted to int which is >> especially bad if that pointer was bigger than 32-bit. >> >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into >> AixNativeThread.c on AIX. >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. We therefore have to map >> them from Java to native every time before calling one of the native poll >> functions and back to Java after the call on AIX in order to get the right >> semantics. >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >> it is not necessary to call Files.getFileAttributeView() with any >> linkOptions because at that place we've already checked that the target file >> can not be a symbolic link. This change makes the implementation more robust >> on platforms which support symbolic links but do not support the O_NOFOLLOW >> flag to the open system call. It also makes the JDK pass the >> demo/zipfs/basic.sh test on AIX. >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The close() subroutine is blocked until all subroutines which use the >> file descriptor return to usr space. For example, when a thread is calling >> close and another thread is calling select with the same file descriptor, >> the close subroutine does not return until the select call returns...". To >> fix this problem, we have to use the various NET_ wrappers which are >> declared in net_util_md.h and defined in aix_close.c and we also need some >> additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some >> more AIX-specifc sections in shared code, I think it is the best way to go >> for JDK 8 because it imposes the smallest possible changes and risks for the >> existing platforms. I'm ready to change the code to unconditionally use the >> wrappers for all platforms and implement the wrappers empty on platforms >> which don't need any wrapping. I think it would also be nice to clean up the >> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >> is probably not appropriate any more so maybe change it to something like >> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an >> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >> descriptor open for writing."). To prevent this error we have to query if >> the corresponding file descriptor is writeable. Notice that at that point we >> can not access the writable attribute of the corresponding file channel so >> we have to use fcntl(). >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system >> call will block if another thread is at the same time blocked in a file >> operation (e.g. 'read()') on the same file descriptor. We therefore combine >> the AIX ProcessPipeInputStream implemenatation with the >> DeferredCloseInputStream approach used on Solaris (see >> UNIXProcess.java.solaris). This means that every potentially blocking >> operation on the file descriptor increments a counter before it is executed >> and decrements it once it finishes. The 'close()' operation will only be >> executed if there are no pending operations. Otherwise it is deferred after >> the last pending operation has finished. >> >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing >> it, otherwise the close() call may be blocked. This is the same problem as >> described before. Unfortunately the JDI framework doesn't use the same IO >> wrappers like other class library components so we can not easily use the >> NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX >> because of the way how the tests act as a "debugger" which launches another >> VM (the "debugge") which connects itself back to the debugger. In this >> scenario the "debugge" can not shut down itself because one thread will >> always be blocked in the close() call on one of the communication sockets. >> >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >> the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should >> read prevTime = newTime;. Otherwise prevTime will never change and the >> timeout will be potential reached too fast. >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID >> to access the proc file system. >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >> with the address family set to AF_UNSPEC. >> >> >> > From volker.simonis at gmail.com Wed Jan 15 09:52:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:52:39 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen < staffan.larsen at oracle.com> >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> Sorry for the noise - it seems I was a little indisposed during the last mails:) So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): @@ -117,19 +119,23 @@ return NULL; } num_commands = (*env)->GetArrayLength(env, commands); - dcmd_info_array = (dcmdInfo*) malloc(num_commands * - sizeof(dcmdInfo)); + dcmdInfoCls = (*env)->FindClass(env, + "sun/management/DiagnosticCommandInfo"); + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); + if (result == NULL) { + JNU_ThrowOutOfMemoryError(env, 0); + } + if (num_commands == 0) { + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ + /* with a zero argument because that may legally return a NULL pointer. */ + return result; + } + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); - dcmdInfoCls = (*env)->FindClass(env, - "sun/management/DiagnosticCommandInfo"); - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); - if (result == NULL) { - free(dcmd_info_array); - JNU_ThrowOutOfMemoryError(env, 0); - } for (i=0; iGetObjectArrayElement(env,commands,i), If the 'commands' input array is of zero length just return a zero length array. OK? >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html ) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm ). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/6fe475ef/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 15 11:02:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:02:26 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Yes, that looks like a good solution. /Staffan On 15 jan 2014, at 17:34, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. > > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > > src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix platforms. >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/7a8e80d0/attachment.html From staffan.larsen at oracle.com Wed Jan 15 11:03:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:03:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <9DE753A4-E6E0-435D-8FB9-5C93CD3184D4@oracle.com> On 15 jan 2014, at 18:27, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! I understood as much :-) > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/c93b7945/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 15 11:04:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:04:50 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <5F6D2785-23EF-4F43-9E0E-649BEF50F204@oracle.com> On 15 jan 2014, at 18:52, Volker Simonis wrote: > > > On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > > wrote: > >> Hi Staffan, > >> > >> thanks for the review. Please find my comments inline: > >> > >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > >> wrote: > >>> > >>> Volker, > >>> > >>> I?ve look at the following files: > >>> > >>> src/share/native/sun/management/DiagnosticCommandImpl.c: > >>> nit: ?legel? -> ?legal? (two times) > >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > >>> you allow dcmd_info_array to become NULL, then > >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to > >>> check that. > >> > >> > >> Good catch. I actually had problems with malloc returning NULL in > >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > >> potentially dangerous locations which used the same pattern. > >> > >> However I think if the 'dcmd_info_array' has zero length it would be > >> perfectly fine to return a zero length array. So what about the following > >> solution: > >> > > Sorry for the noise - it seems I was a little indisposed during the last mails:) > So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): > > > @@ -117,19 +119,23 @@ > return NULL; > } > num_commands = (*env)->GetArrayLength(env, commands); > - dcmd_info_array = (dcmdInfo*) malloc(num_commands * > - sizeof(dcmdInfo)); > + dcmdInfoCls = (*env)->FindClass(env, > + "sun/management/DiagnosticCommandInfo"); > + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > + if (result == NULL) { > + JNU_ThrowOutOfMemoryError(env, 0); > + } > + if (num_commands == 0) { > + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ > + /* with a zero argument because that may legally return a NULL pointer. */ > + return result; > + } > + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > - dcmdInfoCls = (*env)->FindClass(env, > - "sun/management/DiagnosticCommandInfo"); > - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > - if (result == NULL) { > - free(dcmd_info_array); > - JNU_ThrowOutOfMemoryError(env, 0); > - } > for (i=0; i args = getDiagnosticCommandArgumentInfoArray(env, > (*env)->GetObjectArrayElement(env,commands,i), > > If the 'commands' input array is of zero length just return a zero length array. > OK? Yes, this looks good (still :-) ) /Staffan > > >> dcmdInfoCls = (*env)->FindClass(env, > >> "sun/management/DiagnosticCommandInfo"); > >> num_commands = (*env)->GetArrayLength(env, commands); > > > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > > > >> if (num_commands = 0) { > >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > >> if (result == NULL) { > >> JNU_ThrowOutOfMemoryError(env, 0); > >> } > >> else { > >> return result; > >> } > >> } > >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > >> if (dcmd_info_array == NULL) { > >> JNU_ThrowOutOfMemoryError(env, NULL); > >> } > >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > >> > >> That seems easier and saves me from handling the exception. > >> > >> What do you think? > >> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> No comments. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> No comments. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> No comments. > >>> > >>> > >>> Thanks, > >>> /Staffan > >>> > >>> > >>> > >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: > >>> > >>> Hi, > >>> > >>> could you please review the following changes for the ppc-aix-port > >>> stage/stage-9 repositories (the changes are planned for integration into > >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > >>> > >>> I've build and smoke tested without any problems on Linux/x86_64 and > >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > >>> > >>> With these changes (and together with the changes from "8028537: PPC64: > >>> Updated jdk/test scripts to understand the AIX os and environment" and > >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the > >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): > >>> > >>> java/net/Inet6Address/B6558853.java > >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > >>> java/nio/channels/Selector/RacyDeregister.java > >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >>> > >>> Following a detailed description of the various changes: > >>> > >>> src/share/native/java/util/zip/zip_util.c > >>> src/share/native/sun/management/DiagnosticCommandImpl.c > >>> > >>> According to ISO C it is perfectly legal for malloc to return zero if > >>> called with a zero argument. Fix various places where malloc can potentially > >>> correctly return zero because it was called with a zero argument. > >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a > >>> compiler warning on Linux, but on AIX it prevents a VM crash later on > >>> because the return value of malloc() will be casted to int which is > >>> especially bad if that pointer was bigger than 32-bit. > >>> > >>> make/CompileJavaClasses.gmk > >>> > >>> Also use PollingWatchService on AIX. > >>> > >>> make/lib/NioLibraries.gmk > >>> src/aix/native/sun/nio/ch/AixNativeThread.c > >>> > >>> Put the implementation for the native methods of NativeThread into > >>> AixNativeThread.c on AIX. > >>> > >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c > >>> src/solaris/native/sun/nio/ch/Net.c > >>> src/aix/classes/sun/nio/ch/AixPollPort.java > >>> src/aix/native/sun/nio/ch/AixPollPort.c > >>> src/aix/native/java/net/aix_close.c > >>> > >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, > >>> ...) are defined to different values than on other operating systems. The > >>> problem is however, that these constants are hardcoded as public final > >>> static members of various, shared Java classes. We therefore have to map > >>> them from Java to native every time before calling one of the native poll > >>> functions and back to Java after the call on AIX in order to get the right > >>> semantics. > >>> > >>> src/share/classes/java/nio/file/CopyMoveHelper.java > >>> > >>> As discussed on the core-libs mailing list (see > >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > >>> it is not necessary to call Files.getFileAttributeView() with any > >>> linkOptions because at that place we've already checked that the target file > >>> can not be a symbolic link. This change makes the implementation more robust > >>> on platforms which support symbolic links but do not support the O_NOFOLLOW > >>> flag to the open system call. It also makes the JDK pass the > >>> demo/zipfs/basic.sh test on AIX. > >>> > >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > >>> > >>> Support "compound text" on AIX in the same way like on other Unix > >>> platforms. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> > >>> Define the correct attach provider for AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.h > >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > >>> > >>> AIX needs a workaround for I/O cancellation (see: > >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > >>> "..The close() subroutine is blocked until all subroutines which use the > >>> file descriptor return to usr space. For example, when a thread is calling > >>> close and another thread is calling select with the same file descriptor, > >>> the close subroutine does not return until the select call returns...". To > >>> fix this problem, we have to use the various NET_ wrappers which are > >>> declared in net_util_md.h and defined in aix_close.c and we also need some > >>> additional wrappers for fcntl(), read() and write() on AIX. > >>> While the current solution isn't really nice because it introduces some > >>> more AIX-specifc sections in shared code, I think it is the best way to go > >>> for JDK 8 because it imposes the smallest possible changes and risks for the > >>> existing platforms. I'm ready to change the code to unconditionally use the > >>> wrappers for all platforms and implement the wrappers empty on platforms > >>> which don't need any wrapping. I think it would also be nice to clean up the > >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix > >>> is probably not appropriate any more so maybe change it to something like > >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an > >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > >>> descriptor open for writing."). To prevent this error we have to query if > >>> the corresponding file descriptor is writeable. Notice that at that point we > >>> can not access the writable attribute of the corresponding file channel so > >>> we have to use fcntl(). > >>> > >>> src/solaris/classes/java/lang/UNIXProcess.java.aix > >>> > >>> On AIX the implementation is especially tricky, because the close() system > >>> call will block if another thread is at the same time blocked in a file > >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine > >>> the AIX ProcessPipeInputStream implemenatation with the > >>> DeferredCloseInputStream approach used on Solaris (see > >>> UNIXProcess.java.solaris). This means that every potentially blocking > >>> operation on the file descriptor increments a counter before it is executed > >>> and decrements it once it finishes. The 'close()' operation will only be > >>> executed if there are no pending operations. Otherwise it is deferred after > >>> the last pending operation has finished. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> > >>> On AIX we have to call shutdown() on a socket descriptor before closing > >>> it, otherwise the close() call may be blocked. This is the same problem as > >>> described before. Unfortunately the JDI framework doesn't use the same IO > >>> wrappers like other class library components so we can not easily use the > >>> NET_ abstractions from aix_close.c here. > >>> Without this small change all JDI regression tests will fail on AIX > >>> because of the way how the tests act as a "debugger" which launches another > >>> VM (the "debugge") which connects itself back to the debugger. In this > >>> scenario the "debugge" can not shut down itself because one thread will > >>> always be blocked in the close() call on one of the communication sockets. > >>> > >>> src/solaris/native/java/net/NetworkInterface.c > >>> > >>> Set the scope identifier for IPv6 addresses on AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.c > >>> > >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by > >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only > >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to > >>> the same port. > >>> Also fixed a comment and removed unused local variables. > >>> Fixed the obviously inverted assignment newTime = prevTime; which should > >>> read prevTime = newTime;. Otherwise prevTime will never change and the > >>> timeout will be potential reached too fast. > >>> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> > >>> AIX does not understand /proc/self so we have to query the real process ID > >>> to access the proc file system. > >>> > >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > >>> > >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket > >>> with the address family set to AF_UNSPEC. > >>> > >>> > >>> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140115/c4ae36c9/attachment-0001.html From david.holmes at oracle.com Wed Jan 15 19:32:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 13:32:24 +1000 Subject: RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes in C-code. In-Reply-To: <52B39E70.5020500@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6DA2E@DEWDFEMB12A.global.corp.sap> <52B2CFD3.3090303@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE71DA3@DEWDFEMB12A.global.corp.sap> <52B39E70.5020500@oracle.com> Message-ID: <52D752C8.6020502@oracle.com> I had overlooked the fact that these changes had been pushed and was awaiting further discussion. :( I am concerned about the thread state related changes as they are potentially/likely redundant. Thread state transitions generally involve full memory fences as part of the transition. Concerns about store ordering in the lead up to that, eg _last_java_frame, need to be examined in detail to see where the variable is actually read. In many cases you will find that variables are only read in conditions where there has already been explicit synchronization between the threads involved - eg at a safepoint, or when a thread has been suspended etc. Plus I ask again: > With regards to this part of the code do you force UseMembar true for > PPC64? The memory serialization page mechanism is not reliable for > non-TSO systems. Cheers, David ----- On 20/12/2013 11:33 AM, David Holmes wrote: > Hi Goetz, > > On 20/12/2013 12:19 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> the GC stuff is only called from shared code. > > Good to hear. I always wonder though whether the cost of passing the > extra parameter through and checking it, outweighs the benefit of not > issuing the action (the release in this case)? I'm not a compiler person > but perhaps the extra parameter forces parameter passing via the stack > rather than registers, or changes an inlining decision, or maybe the > additional control flow check causes a problem ... Any hard data that > not using release semantics all the time actually yields a benefit? > >> The ordering in BiasedLocking is needed, e.g., in the context of >> force_revoke_and_rebias. >> If an other thread wants to inflate the lock written to the mark word >> in force_revoke_and_rebias, it must be assured that changing the >> displaced >> header is visible to that other thread. > > I'll take your word for it. I don't have time to try and analyse the > BiasedLocking code in depth and I don't think it is a performance issue > for that code given the potentially redundant barrier occurs during a > safepoint anyway. > >> We added the memory barriers for the _thread_state field in 2006 and can >> not reconstruct the concrete cause. But things as setting the >> last_java_frame >> and then the state to in_native should be ordered. > > I am much more concerned about this. I can't accept a simple wrapping of > all accesses with acquire/release semantics because there may be a few > cases where it is needed - this code is too hot for that. We need to > examine the individual cases, like last_java_frame, where you think > there is an issue. > > With regards to this part of the code do you force UseMembar true for > PPC64? The memory serialization page mechanism is not reliable for > non-TSO systems. > > My Xmas break begins in about 5 hours but I will be checking in on email > at times :) > > Cheers, > David > >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 19. Dezember 2013 11:52 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; >> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: Re: RFR (M): 8029396: PPC64 (part 212): Several memory >> ordering fixes in C-code. >> >> Somewhat late but I was away for two weeks. >> >> GC stuff: >> >> Is the use of the new release parameter always set to true from shared >> code? If so I don't have a problem with it being used to optimize the >> stores under certain conditions. But if pcc64 will pass true where other >> archs won't then again I object to this because it should be an >> algorithmic correctness requirement that is always present. >> >> >> General: I find a lot of the commentary excessively platform specific. >> Eg We don't expect any C++ compiler we currently use to emit memory >> barriers for C++ volatiles. If they start doing that we will have a >> bazillion unnecessary injected barriers in our code! >> >> BiasedLocking: >> >> It is not clear to me that the BiasedLocking change is needed. AFAICS >> there is only one path where revoke_bias is not called at a safepoint >> and the comments around that seem to indicate that it was considered >> safe to do so. It may be they assumed TSO when making that decision but >> I'd be interested to know how this change was arrived at. >> >> Thread state: >> >> The thread state changes have me most concerned as they are heavily used >> and so the performance impact here could be extensive. Many of them >> occur on paths that involve membars or membar-equivalent actions so they >> would seem redundant then. Again I would like to see some analysis >> showing these are in fact essential for correctness. There may well be >> some situations where they are, but to me this seems an even better >> candidate for adding the "release" parameter when needed! >> >> David >> ----- >> >> On 3/12/2013 2:51 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This change contains a row of fixes to the memory ordering in >>> runtime, GC etc. >>> http://cr.openjdk.java.net/~goetz/webrevs/8029396-0-memo/ >>> >>> These are: >>> - Accessing arrays in CMS (compactibleFreeListSpace.cpp) >>> - CMS: Do release when marking a card dirty. The release must only be >>> done if GC is running. (several files) >>> - Method counter initialization (method.hpp). >>> - Order accessing f1/f2 in constant pool cache. >>> - Release stores in OopMapCache constructor (instanceKLass.cpp). >>> - BiasedLocking: Release setting object header to displaced mark. >>> - Release state of nmethod sweeper (sweeper.cpp). >>> - Do barriers when writing the thread state (thread.hpp). >>> >>> Please review and test this change. >>> >>> If requested, I can part this into smaller changes. But for now >>> I wanted to put them all into one change as they all address the >>> problems with the PPC memory model. >>> >>> Best regards, >>> Goetz. >>> From david.holmes at oracle.com Wed Jan 15 21:25:36 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 15:25:36 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> Message-ID: <52D76D50.60700@oracle.com> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: > Hi David, > > I updated the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ > > - I removed the IRIW example in parse3.cpp > - I adapted the comments not to point to that comment, and to > reflect the new flagging. Also I mention that we support the > volatile constructor issue, but that it's not standard. > - I protected issuing the barrier for the constructor by PPC64. > I also think it's better to separate these this way. Sorry if I wasn't clear but I'd like the wrote_volatile field declaration and all uses to be guarded by ifdef PPC64 too please. One nit I missed before. In src/share/vm/opto/library_call.cpp this comment doesn't make much sense to me and refers to ppc specific stuff in a shared file: if (is_volatile) { ! if (!is_store) { insert_mem_bar(Op_MemBarAcquire); ! } else { ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. insert_mem_bar(Op_MemBarVolatile); + #endif + } I don't think the comment is needed. Thanks, David > Thanks for your comments! > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 15. Januar 2014 01:55 > To: Lindenmaier, Goetz > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > Sorry for the delay in getting back to this. > > The general changes to the volatile barriers to support IRIW are okay. > The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more > specifically it is > not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of > the commentary excessive, particularly for shared code. In particular > the IRIW example in parse3.cpp - it seems a strange place to give the > explanation and I don't think we need it to that level of detail. Seems > to me that is present is globalDefinitions_ppc.hpp is quite adequate. > > The changes related to volatile writes in the constructor, as discussed > are not required by the Java Memory Model. If you want to keep these > then I think they should all be guarded with PPC64 because it is not > related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the > PPC64 porters. > > Thanks, > David > > On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated this webrev. I detected a small flaw I made when editing this version. >> The #endif in line 322, parse3.cpp was in the wrong line. >> I also based the webrev on the latest version of the stage repo. >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Freitag, 20. Dezember 2013 13:47 >> To: David Holmes >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi David, >> >>> So we can at least undo #4 now we have established those tests were not >>> required to pass. >> We would prefer if we could keep this in. We want to avoid that it's >> blamed on the VM if java programs are failing on PPC after they worked >> on x86. To clearly mark it as overfulfilling the spec I would guard it by >> a flag as proposed. But if you insist I will remove it. Also, this part is >> not that performance relevant. >> >>> A compile-time guard (ifdef) would be better than a runtime one I think >> I added a compile-time guard in this new webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >> several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC) >> but this way I only have to change the ppc platform. >> >> Best regards, >> Goetz >> >> P.S.: I will also be available over the Christmas period. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 20. Dezember 2013 05:58 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Sorry for the delay, it takes a while to catch up after two weeks >> vacation :) Next vacation (ie next two weeks) I'll continue to check emails. >> >> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> ok, I understand the tests are wrong. It's good this issue is settled. >>> Thanks Aleksey and Andreas for going into the details of the proof! >>> >>> About our change: David, the causality is the other way round. >>> The change is about IRIW. >>> 1. To pass IRIW, we must use sync instructions before loads. >> >> This is the part I still have some question marks over as the >> implications are not nice for performance on non-TSO platforms. But I'm >> no further along in processing that paper I'm afraid. >> >>> 2. If we do syncs before loads, we don't need to do them after stores. >>> 3. If we don't do them after stores, we fail the volatile constructor tests. >>> 4. So finally we added them again at the end of the constructor after stores >>> to pass the volatile constructor tests. >> >> So we can at least undo #4 now we have established those tests were not >> required to pass. >> >>> We originally passed the constructor tests because the ppc memory order >>> instructions are not as find-granular as the >>> operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction >>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the >>> MemBarVolatile after the store fixes the constructor tests. The proper representation >>> of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless >>> anyways. >>> >>>> I'm not happy with the ifdef approach but I won't block it. >>> I'd be happy to add a property >>> OrderAccess::cpu_is_multiple_copy_atomic() >> >> A compile-time guard (ifdef) would be better than a runtime one I think >> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >> based not architecture based) as that will allows for turning this >> on/off for any architecture for testing purposes. >> >> Thanks, >> David >> >>> or the like to guard the customization. I'd like that much better. Or also >>> OrderAccess::needs_support_iriw_ordering() >>> VM_Version::needs_support_iriw_ordering() >>> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 28. November 2013 00:34 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> TL;DR version: >>> >>> Discussion on the c-i list has now confirmed that a constructor-barrier >>> for volatiles is not required as part of the JMM specification. It *may* >>> be required in an implementation that doesn't pre-zero memory to ensure >>> you can't see uninitialized fields. So the tests for this are invalid >>> and this part of the patch is not needed in general (ppc64 may need it >>> due to other factors). >>> >>> Re: "multiple copy atomicity" - first thanks for correcting the term :) >>> Second thanks for the reference to that paper! For reference: >>> >>> "The memory system (perhaps involving a hierarchy of buffers and a >>> complex interconnect) does not guarantee that a write becomes visible to >>> all other hardware threads at the same time point; these architectures >>> are not multiple-copy atomic." >>> >>> This is the visibility issue that I referred to and affects both ARM and >>> PPC. But of course it is normally handled by using suitable barriers >>> after the stores that need to be visible. I think the crux of the >>> current issue is what you wrote below: >>> >>> > The fixes for the constructor issue are only needed because we >>> > remove the sync instruction from behind stores (parse3.cpp:320) >>> > and place it before loads. >>> >>> I hadn't grasped this part. Obviously if you fail to do the sync after >>> the store then you have to do something around the loads to get the same >>> results! I still don't know what lead you to the conclusion that the >>> only way to fix the IRIW issue was to put the fence before the load - >>> maybe when I get the chance to read that paper in full it will be clearer. >>> >>> So ... the basic problem is that the current structure in the VM has >>> hard-wired one choice of how to get the right semantics for volatile >>> variables. You now want to customize that but not all the requisite >>> hooks are present. It would be better if volatile_load and >>> volatile_store were factored out so that they could be implemented as >>> desired per-platform. Alternatively there could be pre- and post- hooks >>> that could then be customized per platform. Otherwise you need >>> platform-specific ifdef's to handle it as per your patch. >>> >>> I'm not happy with the ifdef approach but I won't block it. I think this >>> is an area where a lot of clean up is needed in the VM. The barrier >>> abstractions are a confused mess in my opinion. >>> >>> Thanks, >>> David >>> ----- >>> >>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>> >>>> I did not yet add the >>>> OrderAccess::needs_support_iriw_ordering() >>>> VM_Version::needs_support_iriw_ordering() >>>> or >>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>> to reduce #defined, as I got no further comment on that. >>>> >>>> >>>> WRT to the validity of the tests and the interpretation of the JMM >>>> I feel not in the position to contribute substantially. >>>> >>>> But we would like to pass the torture test suite as we consider >>>> this a substantial task in implementing a PPC port. Also we think >>>> both tests show behavior a programmer would expect. It's bad if >>>> Java code runs fine on the more common x86 platform, and then >>>> fails on ppc. This will always first be blamed on the VM. >>>> >>>> The fixes for the constructor issue are only needed because we >>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>> and place it before loads. Then there is no sync between volatile store >>>> and publishing the object. So we add it again in this one case >>>> (volatile store in constructor). >>>> >>>> >>>> @David >>>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>>> and that's being discussed now for almost a year. >>>>> It may have started a year ago but work on it has hardly been continuous. >>>> That's not true, we did a lot of investigation and testing on this issue. >>>> And we came up with a solution we consider the best possible. If you >>>> have objections, you should at least give the draft of a better solution, >>>> we would volunteer to implement and test it. >>>> Similarly, we invested time in fixing the concurrency torture issues. >>>> >>>> @David >>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>>> can't find any reference to it. >>>> We learned about this reading "A Tutorial Introduction to the ARM and >>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>> >>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >>>> instead. Sorry for that. (I also fixed that in the method name above). >>>> >>>> Best regards and thanks for all your involvements, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 27. November 2013 12:53 >>>> To: Lindenmaier, Goetz >>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> -- Volatile in constuctor >>>>>> AFAIK we have not seen those tests fail due to a >>>>>> missing constructor barrier. >>>>> We see them on PPC64. Our test machines have typically 8-32 processors >>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>>> >>>> And see follow ups - the tests are invalid. >>>> >>>>> -- IRIW issue >>>>>> I can not possibly answer to the necessary level of detail with a few >>>>>> moments thought. >>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>> and that's being discussed now for almost a year. >>>> >>>> It may have started a year ago but work on it has hardly been continuous. >>>> >>>>>> You are implying there is a problem here that will >>>>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>>>> solution with the #defines, and that's correct for all, but not nice, I admit. >>>>> (I don't really know about ARM, though). >>>>> So if I can write down a nicer solution testing for methods that are evaluated >>>>> by the C-compiler I'm happy. >>>>> >>>>> The problem is not that IRIW is not handled by the JMM, the problem >>>>> is that >>>>> store >>>>> sync >>>>> does not assure multiple-read-atomicity, >>>>> only >>>>> sync >>>>> load >>>>> does so on PPC. And you require multiple-read-atomicity to >>>>> pass that test. >>>> >>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>> can't find any reference to it. >>>> >>>> Thanks, >>>> David >>>> >>>> The JMM is fine. And >>>>> store >>>>> MemBarVolatile >>>>> is fine on x86, sparc etc. as there exist assembler instructions that >>>>> do what is required. >>>>> >>>>> So if you are off soon, please let's come to a solution that >>>>> might be improvable in the way it's implemented, but that >>>>> allows us to implement a correct PPC64 port. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>> Hi everybody, >>>>>> >>>>>> thanks a lot for the detailed reviews! >>>>>> I'll try to answer to all in one mail. >>>>>> >>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>>>> We don't think it's correct if we omit the barrier after initializing >>>>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>>>> and Doug Lea, and they agreed. >>>>>> Also, concurrency torture tests >>>>>> LongVolatileTest >>>>>> AtomicIntegerInitialValueTest >>>>>> will fail. >>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>>>> >>>>> The affects of unsafe publication are always surprising - volatiles do >>>>> not add anything special here. AFAIK there is nothing in the JMM that >>>>> requires the constructor barrier - discussions with Doug and Aleksey >>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>> missing constructor barrier. >>>>> >>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>>>> see a way to implement this cheaper. >>>>>> >>>>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>>>> Basically, I agree on this. But you also have to take into account >>>>>> that due to the different memory ordering instructions on different platforms >>>>>> just implementing something empty is not sufficient. >>>>>> An example: >>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>> MemBarVolatile // means StoreLoad barrier >>>>>> If these are consecutively in the code, sparc code looks like this: >>>>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>> Just doing what is required. >>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>> fine grained operations: >>>>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>>>> I need an additional optimization that removes the lwsync. I can not implement >>>>>> MemBarRelease empty, as it is also used independently. >>>>>> >>>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>> >>>>>> I would propose to guard the code by >>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>> Else, David, how would you propose to implement this platform independent? >>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>> >>>>> I can not possibly answer to the necessary level of detail with a few >>>>> moments thought. You are implying there is a problem here that will >>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>> different?) and I can not take that on face value at the moment. The >>>>> only reason I can see IRIW not being handled by the JMM requirements for >>>>> volatile accesses is if there are global visibility issues that are not >>>>> addressed - but even then I would expect heavy barriers at the store >>>>> would deal with that, not at the load. (This situation reminds me of the >>>>> need for read-barriers on Alpha architecture due to the use of software >>>>> cache-coherency rather than hardware cache-coherency - but we don't have >>>>> that on ppc!) >>>>> >>>>> Sorry - There is no quick resolution here and in a couple of days I will >>>>> be heading out on vacation for two weeks. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -- Other ports: >>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>>> >>>>>> -- MemBarStoreStore after initialization >>>>>> I agree we should not change it in the ppc port. If you wish, I can >>>>>> prepare an extra webrev for hotspot-comp. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>> To: Vladimir Kozlov >>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>>> >>>>>> Okay this is my second attempt at answering this in a reasonable way :) >>>>>> >>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>> I have to ask David to do correctness evaluation. >>>>>> >>>>>> From what I understand what we see here is an attempt to fix an >>>>>> existing issue with the implementation of volatiles so that the IRIW >>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>>>> load. >>>>>> >>>>>> Now if this was purely handled in ppc64 source code then I would be >>>>>> happy to let them do whatever they like (surely this kills performance >>>>>> though!). But I do not agree with the changes to the shared code that >>>>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>>>> polluting the shared code. My concern is similar to what I said with the >>>>>> taskQueue changes - these algorithms should be expressed using the >>>>>> correct OrderAccess operations to guarantee the desired properties >>>>>> independent of architecture. If such a "barrier" is not needed on a >>>>>> given architecture then the implementation in OrderAccess should reduce >>>>>> to a no-op. >>>>>> >>>>>> And as Vitaly points out the constructor barriers are not needed under >>>>>> the JMM. >>>>>> >>>>>>> I am fine with suggested changes because you did not change our current >>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>> But may be it should be done using more general query which is set >>>>>>> depending on platform: >>>>>>> >>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>> >>>>>>> or similar to what we use now: >>>>>>> >>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>> >>>>>> Every platform has to support IRIW this is simply part of the Java >>>>>> Memory Model, there should not be any need to call this out explicitly >>>>>> like this. >>>>>> >>>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>>>> From what I understand our ppc port is also affected. David? >>>>>> >>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>>>> >>>>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>>> >>>>>>> In do_put_xxx() can you combine your changes: >>>>>>> >>>>>>> if (is_vol) { >>>>>>> // See comment in do_get_xxx(). >>>>>>> #ifndef PPC64 >>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>> #else >>>>>>> if (is_field) { >>>>>>> // Add MemBarRelease for constructors which write volatile field >>>>>>> (PPC64). >>>>>>> set_wrote_volatile(true); >>>>>>> } >>>>>>> #endif >>>>>>> } >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>>>> the torture test suite: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>> >>>>>>>> Example: >>>>>>>> volatile x=0, y=0 >>>>>>>> __________ __________ __________ __________ >>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>> >>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>> read(y) read(x) >>>>>>>> >>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>> >>>>>>>> >>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>>>> assured by the sync instruction and if it is executed in the threads >>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>> >>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>> >>>>>>>> Further this change contains a fix that assures that volatile fields >>>>>>>> written in constructors are visible before the reference gets >>>>>>>> published. >>>>>>>> >>>>>>>> >>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>>>> strong. >>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Please review and test this change. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> From david.holmes at oracle.com Wed Jan 15 21:30:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 15:30:23 +1000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <52B3A3AF.9050609@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> Message-ID: <52D76E6F.8070504@oracle.com> Can I get some response on this please - specifically the redundancy wrt IRT_ENTRY actions. Thanks, David On 20/12/2013 11:55 AM, David Holmes wrote: > Still catching up ... > > On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> this change adds StoreStore barriers after object initialization and >> after constructor calls in the C++ interpreter. This assures no >> uninitialized >> objects or final fields are visible. >> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ > > The InterpreterRuntime calls are all IRT_ENTRY points which will utilize > thread state transitions that already include a full "fence" so the > storestore barriers are redundant in those cases. > > The fastpath _new storestore seems okay. > > I don't know how handle_return gets used to know if it is reasonable or > not. > > I was trying, unsuccessfully, to examine the same code in the > templateInterpreter to see how it handles these cases as it naturally > has the same object-initialization-safety requirements (though these can > be handled in a number of different ways other than an unconditional > storestore barrier at the end of the initialization and construction > phases. > > David > ----- > >> Please review and test this change. >> >> Best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Wed Jan 15 23:13:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Jan 2014 23:13:27 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D76D50.60700@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> Message-ID: <52D78697.2090408@oracle.com> This is becoming ugly #ifdef mess. In compiler code we are trying to avoid them. I suggested to have _wrote_volatile without #ifdef and I want to keep it this way, it could be useful to have such info on other platforms too. But I would suggest to remove PPC64 comments in parse.hpp. In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value which could be checked in all places instead of #ifdef: #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; #else const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; #endif or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever and then: #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ oop p = JNIHandles::resolve(obj); \ + if (support_IRIW_for_not_multiple_copy_atomic_cpu) OrderAccess::fence(); \ volatile type_name v = OrderAccess::load_acquire((volatile type_name*)index_oop_from_field_offset_long(p, offset)); And: + if (support_IRIW_for_not_multiple_copy_atomic_cpu && field->is_volatile()) { + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier + } And so on. The comments will be needed only in globalDefinitions.hpp The code in parse1.cpp could be put on one line: + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && method()->is_initializer()) )) { Thanks, Vladimir On 1/15/14 9:25 PM, David Holmes wrote: > On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I updated the webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >> >> - I removed the IRIW example in parse3.cpp >> - I adapted the comments not to point to that comment, and to >> reflect the new flagging. Also I mention that we support the >> volatile constructor issue, but that it's not standard. >> - I protected issuing the barrier for the constructor by PPC64. >> I also think it's better to separate these this way. > > Sorry if I wasn't clear but I'd like the wrote_volatile field declaration and all uses to be guarded by ifdef PPC64 too > please. > > One nit I missed before. In src/share/vm/opto/library_call.cpp this comment doesn't make much sense to me and refers to > ppc specific stuff in a shared file: > > if (is_volatile) { > ! if (!is_store) { > insert_mem_bar(Op_MemBarAcquire); > ! } else { > ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC > ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. > insert_mem_bar(Op_MemBarVolatile); > + #endif > + } > > I don't think the comment is needed. > > Thanks, > David > >> Thanks for your comments! >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 15. Januar 2014 01:55 >> To: Lindenmaier, Goetz >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> Sorry for the delay in getting back to this. >> >> The general changes to the volatile barriers to support IRIW are okay. >> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >> specifically it is >> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >> the commentary excessive, particularly for shared code. In particular >> the IRIW example in parse3.cpp - it seems a strange place to give the >> explanation and I don't think we need it to that level of detail. Seems >> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >> >> The changes related to volatile writes in the constructor, as discussed >> are not required by the Java Memory Model. If you want to keep these >> then I think they should all be guarded with PPC64 because it is not >> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >> PPC64 porters. >> >> Thanks, >> David >> >> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated this webrev. I detected a small flaw I made when editing this version. >>> The #endif in line 322, parse3.cpp was in the wrong line. >>> I also based the webrev on the latest version of the stage repo. >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Lindenmaier, Goetz >>> Sent: Freitag, 20. Dezember 2013 13:47 >>> To: David Holmes >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi David, >>> >>>> So we can at least undo #4 now we have established those tests were not >>>> required to pass. >>> We would prefer if we could keep this in. We want to avoid that it's >>> blamed on the VM if java programs are failing on PPC after they worked >>> on x86. To clearly mark it as overfulfilling the spec I would guard it by >>> a flag as proposed. But if you insist I will remove it. Also, this part is >>> not that performance relevant. >>> >>>> A compile-time guard (ifdef) would be better than a runtime one I think >>> I added a compile-time guard in this new webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>> several double negations I don't like, (#ifNdef CPU_NOT_MULTIPLE_COPY_ATOMIC) >>> but this way I only have to change the ppc platform. >>> >>> Best regards, >>> Goetz >>> >>> P.S.: I will also be available over the Christmas period. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Freitag, 20. Dezember 2013 05:58 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Sorry for the delay, it takes a while to catch up after two weeks >>> vacation :) Next vacation (ie next two weeks) I'll continue to check emails. >>> >>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> ok, I understand the tests are wrong. It's good this issue is settled. >>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>> >>>> About our change: David, the causality is the other way round. >>>> The change is about IRIW. >>>> 1. To pass IRIW, we must use sync instructions before loads. >>> >>> This is the part I still have some question marks over as the >>> implications are not nice for performance on non-TSO platforms. But I'm >>> no further along in processing that paper I'm afraid. >>> >>>> 2. If we do syncs before loads, we don't need to do them after stores. >>>> 3. If we don't do them after stores, we fail the volatile constructor tests. >>>> 4. So finally we added them again at the end of the constructor after stores >>>> to pass the volatile constructor tests. >>> >>> So we can at least undo #4 now we have established those tests were not >>> required to pass. >>> >>>> We originally passed the constructor tests because the ppc memory order >>>> instructions are not as find-granular as the >>>> operations in the IR. MemBarVolatile is specified as StoreLoad. The only instruction >>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, therefore the >>>> MemBarVolatile after the store fixes the constructor tests. The proper representation >>>> of the fix in the IR would be adding a MemBarStoreStore. But now it's pointless >>>> anyways. >>>> >>>>> I'm not happy with the ifdef approach but I won't block it. >>>> I'd be happy to add a property >>>> OrderAccess::cpu_is_multiple_copy_atomic() >>> >>> A compile-time guard (ifdef) would be better than a runtime one I think >>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>> based not architecture based) as that will allows for turning this >>> on/off for any architecture for testing purposes. >>> >>> Thanks, >>> David >>> >>>> or the like to guard the customization. I'd like that much better. Or also >>>> OrderAccess::needs_support_iriw_ordering() >>>> VM_Version::needs_support_iriw_ordering() >>>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 28. November 2013 00:34 >>>> To: Lindenmaier, Goetz >>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> TL;DR version: >>>> >>>> Discussion on the c-i list has now confirmed that a constructor-barrier >>>> for volatiles is not required as part of the JMM specification. It *may* >>>> be required in an implementation that doesn't pre-zero memory to ensure >>>> you can't see uninitialized fields. So the tests for this are invalid >>>> and this part of the patch is not needed in general (ppc64 may need it >>>> due to other factors). >>>> >>>> Re: "multiple copy atomicity" - first thanks for correcting the term :) >>>> Second thanks for the reference to that paper! For reference: >>>> >>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>> complex interconnect) does not guarantee that a write becomes visible to >>>> all other hardware threads at the same time point; these architectures >>>> are not multiple-copy atomic." >>>> >>>> This is the visibility issue that I referred to and affects both ARM and >>>> PPC. But of course it is normally handled by using suitable barriers >>>> after the stores that need to be visible. I think the crux of the >>>> current issue is what you wrote below: >>>> >>>> > The fixes for the constructor issue are only needed because we >>>> > remove the sync instruction from behind stores (parse3.cpp:320) >>>> > and place it before loads. >>>> >>>> I hadn't grasped this part. Obviously if you fail to do the sync after >>>> the store then you have to do something around the loads to get the same >>>> results! I still don't know what lead you to the conclusion that the >>>> only way to fix the IRIW issue was to put the fence before the load - >>>> maybe when I get the chance to read that paper in full it will be clearer. >>>> >>>> So ... the basic problem is that the current structure in the VM has >>>> hard-wired one choice of how to get the right semantics for volatile >>>> variables. You now want to customize that but not all the requisite >>>> hooks are present. It would be better if volatile_load and >>>> volatile_store were factored out so that they could be implemented as >>>> desired per-platform. Alternatively there could be pre- and post- hooks >>>> that could then be customized per platform. Otherwise you need >>>> platform-specific ifdef's to handle it as per your patch. >>>> >>>> I'm not happy with the ifdef approach but I won't block it. I think this >>>> is an area where a lot of clean up is needed in the VM. The barrier >>>> abstractions are a confused mess in my opinion. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>> >>>>> I did not yet add the >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> VM_Version::needs_support_iriw_ordering() >>>>> or >>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>> to reduce #defined, as I got no further comment on that. >>>>> >>>>> >>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>> I feel not in the position to contribute substantially. >>>>> >>>>> But we would like to pass the torture test suite as we consider >>>>> this a substantial task in implementing a PPC port. Also we think >>>>> both tests show behavior a programmer would expect. It's bad if >>>>> Java code runs fine on the more common x86 platform, and then >>>>> fails on ppc. This will always first be blamed on the VM. >>>>> >>>>> The fixes for the constructor issue are only needed because we >>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>> and place it before loads. Then there is no sync between volatile store >>>>> and publishing the object. So we add it again in this one case >>>>> (volatile store in constructor). >>>>> >>>>> >>>>> @David >>>>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>>>> and that's being discussed now for almost a year. >>>>>> It may have started a year ago but work on it has hardly been continuous. >>>>> That's not true, we did a lot of investigation and testing on this issue. >>>>> And we came up with a solution we consider the best possible. If you >>>>> have objections, you should at least give the draft of a better solution, >>>>> we would volunteer to implement and test it. >>>>> Similarly, we invested time in fixing the concurrency torture issues. >>>>> >>>>> @David >>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>>>> can't find any reference to it. >>>>> We learned about this reading "A Tutorial Introduction to the ARM and >>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>> >>>>> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >>>>> instead. Sorry for that. (I also fixed that in the method name above). >>>>> >>>>> Best regards and thanks for all your involvements, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> -- Volatile in constuctor >>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>> missing constructor barrier. >>>>>> We see them on PPC64. Our test machines have typically 8-32 processors >>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>>>> >>>>> And see follow ups - the tests are invalid. >>>>> >>>>>> -- IRIW issue >>>>>>> I can not possibly answer to the necessary level of detail with a few >>>>>>> moments thought. >>>>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>>>> and that's being discussed now for almost a year. >>>>> >>>>> It may have started a year ago but work on it has hardly been continuous. >>>>> >>>>>>> You are implying there is a problem here that will >>>>>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>>>>> solution with the #defines, and that's correct for all, but not nice, I admit. >>>>>> (I don't really know about ARM, though). >>>>>> So if I can write down a nicer solution testing for methods that are evaluated >>>>>> by the C-compiler I'm happy. >>>>>> >>>>>> The problem is not that IRIW is not handled by the JMM, the problem >>>>>> is that >>>>>> store >>>>>> sync >>>>>> does not assure multiple-read-atomicity, >>>>>> only >>>>>> sync >>>>>> load >>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>> pass that test. >>>>> >>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>>> can't find any reference to it. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> The JMM is fine. And >>>>>> store >>>>>> MemBarVolatile >>>>>> is fine on x86, sparc etc. as there exist assembler instructions that >>>>>> do what is required. >>>>>> >>>>>> So if you are off soon, please let's come to a solution that >>>>>> might be improvable in the way it's implemented, but that >>>>>> allows us to implement a correct PPC64 port. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi everybody, >>>>>>> >>>>>>> thanks a lot for the detailed reviews! >>>>>>> I'll try to answer to all in one mail. >>>>>>> >>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>>>>> We don't think it's correct if we omit the barrier after initializing >>>>>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>>>>> and Doug Lea, and they agreed. >>>>>>> Also, concurrency torture tests >>>>>>> LongVolatileTest >>>>>>> AtomicIntegerInitialValueTest >>>>>>> will fail. >>>>>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>>>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>>>>> >>>>>> The affects of unsafe publication are always surprising - volatiles do >>>>>> not add anything special here. AFAIK there is nothing in the JMM that >>>>>> requires the constructor barrier - discussions with Doug and Aleksey >>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>> missing constructor barrier. >>>>>> >>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>>>>> see a way to implement this cheaper. >>>>>>> >>>>>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>>>>> Basically, I agree on this. But you also have to take into account >>>>>>> that due to the different memory ordering instructions on different platforms >>>>>>> just implementing something empty is not sufficient. >>>>>>> An example: >>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>> If these are consecutively in the code, sparc code looks like this: >>>>>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>> Just doing what is required. >>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>> fine grained operations: >>>>>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>>>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>>>>> I need an additional optimization that removes the lwsync. I can not implement >>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>> >>>>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>> >>>>>>> I would propose to guard the code by >>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>> Else, David, how would you propose to implement this platform independent? >>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>> >>>>>> I can not possibly answer to the necessary level of detail with a few >>>>>> moments thought. You are implying there is a problem here that will >>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>> different?) and I can not take that on face value at the moment. The >>>>>> only reason I can see IRIW not being handled by the JMM requirements for >>>>>> volatile accesses is if there are global visibility issues that are not >>>>>> addressed - but even then I would expect heavy barriers at the store >>>>>> would deal with that, not at the load. (This situation reminds me of the >>>>>> need for read-barriers on Alpha architecture due to the use of software >>>>>> cache-coherency rather than hardware cache-coherency - but we don't have >>>>>> that on ppc!) >>>>>> >>>>>> Sorry - There is no quick resolution here and in a couple of days I will >>>>>> be heading out on vacation for two weeks. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -- Other ports: >>>>>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>>>> >>>>>>> -- MemBarStoreStore after initialization >>>>>>> I agree we should not change it in the ppc port. If you wish, I can >>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>> To: Vladimir Kozlov >>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>>>> >>>>>>> Okay this is my second attempt at answering this in a reasonable way :) >>>>>>> >>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>> I have to ask David to do correctness evaluation. >>>>>>> >>>>>>> From what I understand what we see here is an attempt to fix an >>>>>>> existing issue with the implementation of volatiles so that the IRIW >>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>>>>> load. >>>>>>> >>>>>>> Now if this was purely handled in ppc64 source code then I would be >>>>>>> happy to let them do whatever they like (surely this kills performance >>>>>>> though!). But I do not agree with the changes to the shared code that >>>>>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>>>>> polluting the shared code. My concern is similar to what I said with the >>>>>>> taskQueue changes - these algorithms should be expressed using the >>>>>>> correct OrderAccess operations to guarantee the desired properties >>>>>>> independent of architecture. If such a "barrier" is not needed on a >>>>>>> given architecture then the implementation in OrderAccess should reduce >>>>>>> to a no-op. >>>>>>> >>>>>>> And as Vitaly points out the constructor barriers are not needed under >>>>>>> the JMM. >>>>>>> >>>>>>>> I am fine with suggested changes because you did not change our current >>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>> But may be it should be done using more general query which is set >>>>>>>> depending on platform: >>>>>>>> >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> >>>>>>>> or similar to what we use now: >>>>>>>> >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>> >>>>>>> Every platform has to support IRIW this is simply part of the Java >>>>>>> Memory Model, there should not be any need to call this out explicitly >>>>>>> like this. >>>>>>> >>>>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>>>>> From what I understand our ppc port is also affected. David? >>>>>>> >>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>>>>> >>>>>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>>>> >>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>> >>>>>>>> if (is_vol) { >>>>>>>> // See comment in do_get_xxx(). >>>>>>>> #ifndef PPC64 >>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>> #else >>>>>>>> if (is_field) { >>>>>>>> // Add MemBarRelease for constructors which write volatile field >>>>>>>> (PPC64). >>>>>>>> set_wrote_volatile(true); >>>>>>>> } >>>>>>>> #endif >>>>>>>> } >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>>>>> the torture test suite: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>> >>>>>>>>> Example: >>>>>>>>> volatile x=0, y=0 >>>>>>>>> __________ __________ __________ __________ >>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>> >>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>> read(y) read(x) >>>>>>>>> >>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>> >>>>>>>>> >>>>>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>>>>> assured by the sync instruction and if it is executed in the threads >>>>>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>> >>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>> >>>>>>>>> Further this change contains a fix that assures that volatile fields >>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>> published. >>>>>>>>> >>>>>>>>> >>>>>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>>>>> strong. >>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Please review and test this change. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> From volker.simonis at gmail.com Thu Jan 16 00:08:35 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 09:08:35 +0100 Subject: RFR(S): JDK-8031134 : PPC64: implement printing on AIX Message-ID: Resending one more time to 2d-dev upon request: Hi, could somebody please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8031134/ It's the straight forward implementation of the basic printing infrastructure on AIX and shouldn't have any impact on the existing platforms. As always, this change is intended for the http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. Thank you and best regards, Volker From david.holmes at oracle.com Thu Jan 16 00:34:10 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 18:34:10 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D78697.2090408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> Message-ID: <52D79982.4060100@oracle.com> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: > This is becoming ugly #ifdef mess. In compiler code we are trying to > avoid them. I suggested to have _wrote_volatile without #ifdef and I > want to keep it this way, it could be useful to have such info on other > platforms too. But I would suggest to remove PPC64 comments in parse.hpp. > > In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value > which could be checked in all places instead of #ifdef: I asked for the ifdef some time back as I find it much preferable to have this as a build-time construct rather than a runtime one. I don't want to have to pay anything for this if we don't use it. David > #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC > const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; > #else > const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; > #endif > > or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever > > and then: > > #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ > oop p = JNIHandles::resolve(obj); \ > + if (support_IRIW_for_not_multiple_copy_atomic_cpu) > OrderAccess::fence(); \ > volatile type_name v = OrderAccess::load_acquire((volatile > type_name*)index_oop_from_field_offset_long(p, offset)); > > And: > > + if (support_IRIW_for_not_multiple_copy_atomic_cpu && > field->is_volatile()) { > + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier > + } > > And so on. The comments will be needed only in globalDefinitions.hpp > > The code in parse1.cpp could be put on one line: > > + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && > method()->is_initializer()) )) { > > Thanks, > Vladimir > > On 1/15/14 9:25 PM, David Holmes wrote: >> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> I updated the webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>> >>> - I removed the IRIW example in parse3.cpp >>> - I adapted the comments not to point to that comment, and to >>> reflect the new flagging. Also I mention that we support the >>> volatile constructor issue, but that it's not standard. >>> - I protected issuing the barrier for the constructor by PPC64. >>> I also think it's better to separate these this way. >> >> Sorry if I wasn't clear but I'd like the wrote_volatile field >> declaration and all uses to be guarded by ifdef PPC64 too >> please. >> >> One nit I missed before. In src/share/vm/opto/library_call.cpp this >> comment doesn't make much sense to me and refers to >> ppc specific stuff in a shared file: >> >> if (is_volatile) { >> ! if (!is_store) { >> insert_mem_bar(Op_MemBarAcquire); >> ! } else { >> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >> insert_mem_bar(Op_MemBarVolatile); >> + #endif >> + } >> >> I don't think the comment is needed. >> >> Thanks, >> David >> >>> Thanks for your comments! >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 15. Januar 2014 01:55 >>> To: Lindenmaier, Goetz >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>> Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> Sorry for the delay in getting back to this. >>> >>> The general changes to the volatile barriers to support IRIW are okay. >>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>> specifically it is >>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>> the commentary excessive, particularly for shared code. In particular >>> the IRIW example in parse3.cpp - it seems a strange place to give the >>> explanation and I don't think we need it to that level of detail. Seems >>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>> >>> The changes related to volatile writes in the constructor, as discussed >>> are not required by the Java Memory Model. If you want to keep these >>> then I think they should all be guarded with PPC64 because it is not >>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>> PPC64 porters. >>> >>> Thanks, >>> David >>> >>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I updated this webrev. I detected a small flaw I made when editing >>>> this version. >>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>> I also based the webrev on the latest version of the stage repo. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>> To: David Holmes >>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>> Independent Reads of Independent Writes >>>> >>>> Hi David, >>>> >>>>> So we can at least undo #4 now we have established those tests were >>>>> not >>>>> required to pass. >>>> We would prefer if we could keep this in. We want to avoid that it's >>>> blamed on the VM if java programs are failing on PPC after they worked >>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>> it by >>>> a flag as proposed. But if you insist I will remove it. Also, this >>>> part is >>>> not that performance relevant. >>>> >>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>> think >>>> I added a compile-time guard in this new webrev: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>> several double negations I don't like, (#ifNdef >>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>> but this way I only have to change the ppc platform. >>>> >>>> Best regards, >>>> Goetz >>>> >>>> P.S.: I will also be available over the Christmas period. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>> To: Lindenmaier, Goetz >>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>> Independent Reads of Independent Writes >>>> >>>> Sorry for the delay, it takes a while to catch up after two weeks >>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>> emails. >>>> >>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> ok, I understand the tests are wrong. It's good this issue is >>>>> settled. >>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>> >>>>> About our change: David, the causality is the other way round. >>>>> The change is about IRIW. >>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>> >>>> This is the part I still have some question marks over as the >>>> implications are not nice for performance on non-TSO platforms. But I'm >>>> no further along in processing that paper I'm afraid. >>>> >>>>> 2. If we do syncs before loads, we don't need to do them after stores. >>>>> 3. If we don't do them after stores, we fail the volatile >>>>> constructor tests. >>>>> 4. So finally we added them again at the end of the constructor >>>>> after stores >>>>> to pass the volatile constructor tests. >>>> >>>> So we can at least undo #4 now we have established those tests were not >>>> required to pass. >>>> >>>>> We originally passed the constructor tests because the ppc memory >>>>> order >>>>> instructions are not as find-granular as the >>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>> The only instruction >>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>> therefore the >>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>> proper representation >>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>> it's pointless >>>>> anyways. >>>>> >>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>> I'd be happy to add a property >>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>> >>>> A compile-time guard (ifdef) would be better than a runtime one I think >>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>> based not architecture based) as that will allows for turning this >>>> on/off for any architecture for testing purposes. >>>> >>>> Thanks, >>>> David >>>> >>>>> or the like to guard the customization. I'd like that much better. >>>>> Or also >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> VM_Version::needs_support_iriw_ordering() >>>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>> Independent Reads of Independent Writes >>>>> >>>>> TL;DR version: >>>>> >>>>> Discussion on the c-i list has now confirmed that a >>>>> constructor-barrier >>>>> for volatiles is not required as part of the JMM specification. It >>>>> *may* >>>>> be required in an implementation that doesn't pre-zero memory to >>>>> ensure >>>>> you can't see uninitialized fields. So the tests for this are invalid >>>>> and this part of the patch is not needed in general (ppc64 may need it >>>>> due to other factors). >>>>> >>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>> term :) >>>>> Second thanks for the reference to that paper! For reference: >>>>> >>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>> complex interconnect) does not guarantee that a write becomes >>>>> visible to >>>>> all other hardware threads at the same time point; these architectures >>>>> are not multiple-copy atomic." >>>>> >>>>> This is the visibility issue that I referred to and affects both >>>>> ARM and >>>>> PPC. But of course it is normally handled by using suitable barriers >>>>> after the stores that need to be visible. I think the crux of the >>>>> current issue is what you wrote below: >>>>> >>>>> > The fixes for the constructor issue are only needed because we >>>>> > remove the sync instruction from behind stores (parse3.cpp:320) >>>>> > and place it before loads. >>>>> >>>>> I hadn't grasped this part. Obviously if you fail to do the sync after >>>>> the store then you have to do something around the loads to get the >>>>> same >>>>> results! I still don't know what lead you to the conclusion that the >>>>> only way to fix the IRIW issue was to put the fence before the load - >>>>> maybe when I get the chance to read that paper in full it will be >>>>> clearer. >>>>> >>>>> So ... the basic problem is that the current structure in the VM has >>>>> hard-wired one choice of how to get the right semantics for volatile >>>>> variables. You now want to customize that but not all the requisite >>>>> hooks are present. It would be better if volatile_load and >>>>> volatile_store were factored out so that they could be implemented as >>>>> desired per-platform. Alternatively there could be pre- and post- >>>>> hooks >>>>> that could then be customized per platform. Otherwise you need >>>>> platform-specific ifdef's to handle it as per your patch. >>>>> >>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>> this >>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>> abstractions are a confused mess in my opinion. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>> >>>>>> I did not yet add the >>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>> VM_Version::needs_support_iriw_ordering() >>>>>> or >>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>> to reduce #defined, as I got no further comment on that. >>>>>> >>>>>> >>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>> I feel not in the position to contribute substantially. >>>>>> >>>>>> But we would like to pass the torture test suite as we consider >>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>> Java code runs fine on the more common x86 platform, and then >>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>> >>>>>> The fixes for the constructor issue are only needed because we >>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>> and place it before loads. Then there is no sync between volatile >>>>>> store >>>>>> and publishing the object. So we add it again in this one case >>>>>> (volatile store in constructor). >>>>>> >>>>>> >>>>>> @David >>>>>>>> Sure. There also is no solution as you require for the >>>>>>>> taskqueue problem yet, >>>>>>>> and that's being discussed now for almost a year. >>>>>>> It may have started a year ago but work on it has hardly been >>>>>>> continuous. >>>>>> That's not true, we did a lot of investigation and testing on this >>>>>> issue. >>>>>> And we came up with a solution we consider the best possible. If you >>>>>> have objections, you should at least give the draft of a better >>>>>> solution, >>>>>> we would volunteer to implement and test it. >>>>>> Similarly, we invested time in fixing the concurrency torture issues. >>>>>> >>>>>> @David >>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>> and >>>>>>> can't find any reference to it. >>>>>> We learned about this reading "A Tutorial Introduction to the ARM and >>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>> Work-Stealing for >>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>> taskqueue problem. >>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>> >>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>> used 'read' >>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>> above). >>>>>> >>>>>> Best regards and thanks for all your involvements, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> -- Volatile in constuctor >>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>> missing constructor barrier. >>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>> processors >>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>>>>> >>>>>> And see follow ups - the tests are invalid. >>>>>> >>>>>>> -- IRIW issue >>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>> a few >>>>>>>> moments thought. >>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>> problem yet, >>>>>>> and that's being discussed now for almost a year. >>>>>> >>>>>> It may have started a year ago but work on it has hardly been >>>>>> continuous. >>>>>> >>>>>>>> You are implying there is a problem here that will >>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>> different?) >>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>> I contributed a >>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>> nice, I admit. >>>>>>> (I don't really know about ARM, though). >>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>> are evaluated >>>>>>> by the C-compiler I'm happy. >>>>>>> >>>>>>> The problem is not that IRIW is not handled by the JMM, the problem >>>>>>> is that >>>>>>> store >>>>>>> sync >>>>>>> does not assure multiple-read-atomicity, >>>>>>> only >>>>>>> sync >>>>>>> load >>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>> pass that test. >>>>>> >>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>>>> can't find any reference to it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> The JMM is fine. And >>>>>>> store >>>>>>> MemBarVolatile >>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>> that >>>>>>> do what is required. >>>>>>> >>>>>>> So if you are off soon, please let's come to a solution that >>>>>>> might be improvable in the way it's implemented, but that >>>>>>> allows us to implement a correct PPC64 port. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>> 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi everybody, >>>>>>>> >>>>>>>> thanks a lot for the detailed reviews! >>>>>>>> I'll try to answer to all in one mail. >>>>>>>> >>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>> to occur before the reference is assigned; >>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>> initializing >>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>> Shipilev >>>>>>>> and Doug Lea, and they agreed. >>>>>>>> Also, concurrency torture tests >>>>>>>> LongVolatileTest >>>>>>>> AtomicIntegerInitialValueTest >>>>>>>> will fail. >>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>> volatile field would be >>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>> AtomicInteger.) >>>>>>> >>>>>>> The affects of unsafe publication are always surprising - >>>>>>> volatiles do >>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>> that >>>>>>> requires the constructor barrier - discussions with Doug and Aleksey >>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>> missing constructor barrier. >>>>>>> >>>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>> don't >>>>>>>> see a way to implement this cheaper. >>>>>>>> >>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>> OrderAccess operations >>>>>>>> Basically, I agree on this. But you also have to take into account >>>>>>>> that due to the different memory ordering instructions on >>>>>>>> different platforms >>>>>>>> just implementing something empty is not sufficient. >>>>>>>> An example: >>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>> If these are consecutively in the code, sparc code looks like this: >>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>> Assembler::StoreStore) >>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>> Just doing what is required. >>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>> fine grained operations: >>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>> StoreStore, LoadLoad >>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>> are more (too) powerful, >>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>> can not implement >>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>> >>>>>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>> read >>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>> >>>>>>>> I would propose to guard the code by >>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>> independent? >>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>> >>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>> few >>>>>>> moments thought. You are implying there is a problem here that will >>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>> different?) and I can not take that on face value at the moment. The >>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>> requirements for >>>>>>> volatile accesses is if there are global visibility issues that >>>>>>> are not >>>>>>> addressed - but even then I would expect heavy barriers at the store >>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>> of the >>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>> software >>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>> don't have >>>>>>> that on ppc!) >>>>>>> >>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>> I will >>>>>>> be heading out on vacation for two weeks. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -- Other ports: >>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>> it might >>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>>>>> >>>>>>>> -- MemBarStoreStore after initialization >>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>> can >>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>> To: Vladimir Kozlov >>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>> way :) >>>>>>>> >>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>> >>>>>>>> From what I understand what we see here is an attempt to >>>>>>>> fix an >>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>> IRIW >>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>> doing the >>>>>>>> load. >>>>>>>> >>>>>>>> Now if this was purely handled in ppc64 source code then I would be >>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>> performance >>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>> that >>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>> this is >>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>> with the >>>>>>>> taskQueue changes - these algorithms should be expressed using the >>>>>>>> correct OrderAccess operations to guarantee the desired properties >>>>>>>> independent of architecture. If such a "barrier" is not needed on a >>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>> reduce >>>>>>>> to a no-op. >>>>>>>> >>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>> under >>>>>>>> the JMM. >>>>>>>> >>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>> current >>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>> But may be it should be done using more general query which is set >>>>>>>>> depending on platform: >>>>>>>>> >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> >>>>>>>>> or similar to what we use now: >>>>>>>>> >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> >>>>>>>> Every platform has to support IRIW this is simply part of the Java >>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>> explicitly >>>>>>>> like this. >>>>>>>> >>>>>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>> defines? >>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>> David? >>>>>>>> >>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>> inside else {}. >>>>>>>>> >>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>> specific which >>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>> PPC64_ONLY() >>>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>>>>> >>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>> >>>>>>>>> if (is_vol) { >>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>> #ifndef PPC64 >>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>> #else >>>>>>>>> if (is_field) { >>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>> volatile field >>>>>>>>> (PPC64). >>>>>>>>> set_wrote_volatile(true); >>>>>>>>> } >>>>>>>>> #endif >>>>>>>>> } >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>> VolatileIRIWTest of >>>>>>>>>> the torture test suite: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>> >>>>>>>>>> Example: >>>>>>>>>> volatile x=0, y=0 >>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>> >>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>> read(y) read(x) >>>>>>>>>> >>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>> is only >>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>> threads >>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>> sync-load-acquire >>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>> >>>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>> >>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>> fields >>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>> published. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>> seems too >>>>>>>>>> strong. >>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>> suffice. >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Please review and test this change. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> From vladimir.kozlov at oracle.com Thu Jan 16 00:54:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 00:54:57 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D79982.4060100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> Message-ID: <52D79E61.1060801@oracle.com> On 1/16/14 12:34 AM, David Holmes wrote: > On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >> This is becoming ugly #ifdef mess. In compiler code we are trying to >> avoid them. I suggested to have _wrote_volatile without #ifdef and I >> want to keep it this way, it could be useful to have such info on other >> platforms too. But I would suggest to remove PPC64 comments in parse.hpp. >> >> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >> which could be checked in all places instead of #ifdef: > > I asked for the ifdef some time back as I find it much preferable to have this as a build-time construct rather than a > runtime one. I don't want to have to pay anything for this if we don't use it. Any decent C++ compiler will optimize expressions with such constants defined in header files. I insist to avoid #ifdefs in C2 code. I really don't like the code with #ifdef in unsafe.cpp but I can live with it. Vladimir > > David > >> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >> #else >> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >> #endif >> >> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >> >> and then: >> >> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >> oop p = JNIHandles::resolve(obj); \ >> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >> OrderAccess::fence(); \ >> volatile type_name v = OrderAccess::load_acquire((volatile >> type_name*)index_oop_from_field_offset_long(p, offset)); >> >> And: >> >> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >> field->is_volatile()) { >> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >> + } >> >> And so on. The comments will be needed only in globalDefinitions.hpp >> >> The code in parse1.cpp could be put on one line: >> >> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >> method()->is_initializer()) )) { >> >> Thanks, >> Vladimir >> >> On 1/15/14 9:25 PM, David Holmes wrote: >>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> I updated the webrev: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>> >>>> - I removed the IRIW example in parse3.cpp >>>> - I adapted the comments not to point to that comment, and to >>>> reflect the new flagging. Also I mention that we support the >>>> volatile constructor issue, but that it's not standard. >>>> - I protected issuing the barrier for the constructor by PPC64. >>>> I also think it's better to separate these this way. >>> >>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>> declaration and all uses to be guarded by ifdef PPC64 too >>> please. >>> >>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>> comment doesn't make much sense to me and refers to >>> ppc specific stuff in a shared file: >>> >>> if (is_volatile) { >>> ! if (!is_store) { >>> insert_mem_bar(Op_MemBarAcquire); >>> ! } else { >>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>> insert_mem_bar(Op_MemBarVolatile); >>> + #endif >>> + } >>> >>> I don't think the comment is needed. >>> >>> Thanks, >>> David >>> >>>> Thanks for your comments! >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>> To: Lindenmaier, Goetz >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>> Independent Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> Sorry for the delay in getting back to this. >>>> >>>> The general changes to the volatile barriers to support IRIW are okay. >>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>> specifically it is >>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>> the commentary excessive, particularly for shared code. In particular >>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>> explanation and I don't think we need it to that level of detail. Seems >>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>> >>>> The changes related to volatile writes in the constructor, as discussed >>>> are not required by the Java Memory Model. If you want to keep these >>>> then I think they should all be guarded with PPC64 because it is not >>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>> PPC64 porters. >>>> >>>> Thanks, >>>> David >>>> >>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I updated this webrev. I detected a small flaw I made when editing >>>>> this version. >>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>> I also based the webrev on the latest version of the stage repo. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Lindenmaier, Goetz >>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>> To: David Holmes >>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>> Independent Reads of Independent Writes >>>>> >>>>> Hi David, >>>>> >>>>>> So we can at least undo #4 now we have established those tests were >>>>>> not >>>>>> required to pass. >>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>> blamed on the VM if java programs are failing on PPC after they worked >>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>> it by >>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>> part is >>>>> not that performance relevant. >>>>> >>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>> think >>>>> I added a compile-time guard in this new webrev: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>> several double negations I don't like, (#ifNdef >>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>> but this way I only have to change the ppc platform. >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>> P.S.: I will also be available over the Christmas period. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>> Independent Reads of Independent Writes >>>>> >>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>> emails. >>>>> >>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>> settled. >>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>> >>>>>> About our change: David, the causality is the other way round. >>>>>> The change is about IRIW. >>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>> >>>>> This is the part I still have some question marks over as the >>>>> implications are not nice for performance on non-TSO platforms. But I'm >>>>> no further along in processing that paper I'm afraid. >>>>> >>>>>> 2. If we do syncs before loads, we don't need to do them after stores. >>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>> constructor tests. >>>>>> 4. So finally we added them again at the end of the constructor >>>>>> after stores >>>>>> to pass the volatile constructor tests. >>>>> >>>>> So we can at least undo #4 now we have established those tests were not >>>>> required to pass. >>>>> >>>>>> We originally passed the constructor tests because the ppc memory >>>>>> order >>>>>> instructions are not as find-granular as the >>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>> The only instruction >>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>> therefore the >>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>> proper representation >>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>> it's pointless >>>>>> anyways. >>>>>> >>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>> I'd be happy to add a property >>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>> >>>>> A compile-time guard (ifdef) would be better than a runtime one I think >>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>> based not architecture based) as that will allows for turning this >>>>> on/off for any architecture for testing purposes. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> or the like to guard the customization. I'd like that much better. >>>>>> Or also >>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>> VM_Version::needs_support_iriw_ordering() >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> TL;DR version: >>>>>> >>>>>> Discussion on the c-i list has now confirmed that a >>>>>> constructor-barrier >>>>>> for volatiles is not required as part of the JMM specification. It >>>>>> *may* >>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>> ensure >>>>>> you can't see uninitialized fields. So the tests for this are invalid >>>>>> and this part of the patch is not needed in general (ppc64 may need it >>>>>> due to other factors). >>>>>> >>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>> term :) >>>>>> Second thanks for the reference to that paper! For reference: >>>>>> >>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>> complex interconnect) does not guarantee that a write becomes >>>>>> visible to >>>>>> all other hardware threads at the same time point; these architectures >>>>>> are not multiple-copy atomic." >>>>>> >>>>>> This is the visibility issue that I referred to and affects both >>>>>> ARM and >>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>> after the stores that need to be visible. I think the crux of the >>>>>> current issue is what you wrote below: >>>>>> >>>>>> > The fixes for the constructor issue are only needed because we >>>>>> > remove the sync instruction from behind stores (parse3.cpp:320) >>>>>> > and place it before loads. >>>>>> >>>>>> I hadn't grasped this part. Obviously if you fail to do the sync after >>>>>> the store then you have to do something around the loads to get the >>>>>> same >>>>>> results! I still don't know what lead you to the conclusion that the >>>>>> only way to fix the IRIW issue was to put the fence before the load - >>>>>> maybe when I get the chance to read that paper in full it will be >>>>>> clearer. >>>>>> >>>>>> So ... the basic problem is that the current structure in the VM has >>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>> variables. You now want to customize that but not all the requisite >>>>>> hooks are present. It would be better if volatile_load and >>>>>> volatile_store were factored out so that they could be implemented as >>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>> hooks >>>>>> that could then be customized per platform. Otherwise you need >>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>> >>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>> this >>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>> abstractions are a confused mess in my opinion. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>> >>>>>>> I did not yet add the >>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>> or >>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>> >>>>>>> >>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>> I feel not in the position to contribute substantially. >>>>>>> >>>>>>> But we would like to pass the torture test suite as we consider >>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>> >>>>>>> The fixes for the constructor issue are only needed because we >>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>> store >>>>>>> and publishing the object. So we add it again in this one case >>>>>>> (volatile store in constructor). >>>>>>> >>>>>>> >>>>>>> @David >>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>> taskqueue problem yet, >>>>>>>>> and that's being discussed now for almost a year. >>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>> continuous. >>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>> issue. >>>>>>> And we came up with a solution we consider the best possible. If you >>>>>>> have objections, you should at least give the draft of a better >>>>>>> solution, >>>>>>> we would volunteer to implement and test it. >>>>>>> Similarly, we invested time in fixing the concurrency torture issues. >>>>>>> >>>>>>> @David >>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>> and >>>>>>>> can't find any reference to it. >>>>>>> We learned about this reading "A Tutorial Introduction to the ARM and >>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>> Work-Stealing for >>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>> taskqueue problem. >>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>> >>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>> used 'read' >>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>> above). >>>>>>> >>>>>>> Best regards and thanks for all your involvements, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> -- Volatile in constuctor >>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>> missing constructor barrier. >>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>> processors >>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>>>>>> >>>>>>> And see follow ups - the tests are invalid. >>>>>>> >>>>>>>> -- IRIW issue >>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>> a few >>>>>>>>> moments thought. >>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>> problem yet, >>>>>>>> and that's being discussed now for almost a year. >>>>>>> >>>>>>> It may have started a year ago but work on it has hardly been >>>>>>> continuous. >>>>>>> >>>>>>>>> You are implying there is a problem here that will >>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>> different?) >>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>> I contributed a >>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>> nice, I admit. >>>>>>>> (I don't really know about ARM, though). >>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>> are evaluated >>>>>>>> by the C-compiler I'm happy. >>>>>>>> >>>>>>>> The problem is not that IRIW is not handled by the JMM, the problem >>>>>>>> is that >>>>>>>> store >>>>>>>> sync >>>>>>>> does not assure multiple-read-atomicity, >>>>>>>> only >>>>>>>> sync >>>>>>>> load >>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>> pass that test. >>>>>>> >>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>>>>>> can't find any reference to it. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> The JMM is fine. And >>>>>>>> store >>>>>>>> MemBarVolatile >>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>> that >>>>>>>> do what is required. >>>>>>>> >>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>> 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi everybody, >>>>>>>>> >>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>> >>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>> to occur before the reference is assigned; >>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>> initializing >>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>> Shipilev >>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>> Also, concurrency torture tests >>>>>>>>> LongVolatileTest >>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>> will fail. >>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>> volatile field would be >>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>> AtomicInteger.) >>>>>>>> >>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>> volatiles do >>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>> that >>>>>>>> requires the constructor barrier - discussions with Doug and Aleksey >>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>> missing constructor barrier. >>>>>>>> >>>>>>>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>> don't >>>>>>>>> see a way to implement this cheaper. >>>>>>>>> >>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>> OrderAccess operations >>>>>>>>> Basically, I agree on this. But you also have to take into account >>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>> different platforms >>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>> An example: >>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>> If these are consecutively in the code, sparc code looks like this: >>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>> Assembler::StoreStore) >>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>> Just doing what is required. >>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>> fine grained operations: >>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>> StoreStore, LoadLoad >>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>> are more (too) powerful, >>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>> can not implement >>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>> >>>>>>>>> Back to the IRIW problem. I think here we have a comparable issue. >>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>> read >>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>> >>>>>>>>> I would propose to guard the code by >>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>> independent? >>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>> >>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>> few >>>>>>>> moments thought. You are implying there is a problem here that will >>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>> different?) and I can not take that on face value at the moment. The >>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>> requirements for >>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>> are not >>>>>>>> addressed - but even then I would expect heavy barriers at the store >>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>> of the >>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>> software >>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>> don't have >>>>>>>> that on ppc!) >>>>>>>> >>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>> I will >>>>>>>> be heading out on vacation for two weeks. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -- Other ports: >>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>> it might >>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>>>>>>> >>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>> can >>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>> To: Vladimir Kozlov >>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>> way :) >>>>>>>>> >>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>> >>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>> fix an >>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>> IRIW >>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>> doing the >>>>>>>>> load. >>>>>>>>> >>>>>>>>> Now if this was purely handled in ppc64 source code then I would be >>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>> performance >>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>> that >>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>> this is >>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>> with the >>>>>>>>> taskQueue changes - these algorithms should be expressed using the >>>>>>>>> correct OrderAccess operations to guarantee the desired properties >>>>>>>>> independent of architecture. If such a "barrier" is not needed on a >>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>> reduce >>>>>>>>> to a no-op. >>>>>>>>> >>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>> under >>>>>>>>> the JMM. >>>>>>>>> >>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>> current >>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>> But may be it should be done using more general query which is set >>>>>>>>>> depending on platform: >>>>>>>>>> >>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>> >>>>>>>>>> or similar to what we use now: >>>>>>>>>> >>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> >>>>>>>>> Every platform has to support IRIW this is simply part of the Java >>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>> explicitly >>>>>>>>> like this. >>>>>>>>> >>>>>>>>> Is there some subtlety of the hardware I am missing here? Are there >>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>> defines? >>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>> David? >>>>>>>>> >>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>> inside else {}. >>>>>>>>>> >>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>> specific which >>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>> PPC64_ONLY() >>>>>>>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>>>>>>> >>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>> >>>>>>>>>> if (is_vol) { >>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>> #ifndef PPC64 >>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>> #else >>>>>>>>>> if (is_field) { >>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>> volatile field >>>>>>>>>> (PPC64). >>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>> } >>>>>>>>>> #endif >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>> the torture test suite: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>> >>>>>>>>>>> Example: >>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>> >>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>> read(y) read(x) >>>>>>>>>>> >>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>> is only >>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>> threads >>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>> sync-load-acquire >>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>> >>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>> >>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>> fields >>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>> published. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>> seems too >>>>>>>>>>> strong. >>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>> suffice. >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Please review and test this change. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> From david.holmes at oracle.com Thu Jan 16 01:04:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 19:04:41 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D79E61.1060801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> Message-ID: <52D7A0A9.6070208@oracle.com> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: > On 1/16/14 12:34 AM, David Holmes wrote: >> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>> want to keep it this way, it could be useful to have such info on other >>> platforms too. But I would suggest to remove PPC64 comments in >>> parse.hpp. >>> >>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>> which could be checked in all places instead of #ifdef: >> >> I asked for the ifdef some time back as I find it much preferable to >> have this as a build-time construct rather than a >> runtime one. I don't want to have to pay anything for this if we don't >> use it. > > Any decent C++ compiler will optimize expressions with such constants > defined in header files. I insist to avoid #ifdefs in C2 code. I really > don't like the code with #ifdef in unsafe.cpp but I can live with it. If you insist then we may as well do it all the same way. Better to be consistent. My apologies Goetz for wasting your time going back and forth on this. That aside I have a further concern with this IRIW support - it is incomplete as there is no C1 support, as PPC64 isn't using client. If this is going on then we (which probably means the Oracle 'we') need to add the missing C1 code. David ----- > Vladimir > >> >> David >> >>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>> #else >>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>> #endif >>> >>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>> >>> and then: >>> >>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>> oop p = JNIHandles::resolve(obj); \ >>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>> OrderAccess::fence(); \ >>> volatile type_name v = OrderAccess::load_acquire((volatile >>> type_name*)index_oop_from_field_offset_long(p, offset)); >>> >>> And: >>> >>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>> field->is_volatile()) { >>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>> + } >>> >>> And so on. The comments will be needed only in globalDefinitions.hpp >>> >>> The code in parse1.cpp could be put on one line: >>> >>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>> method()->is_initializer()) )) { >>> >>> Thanks, >>> Vladimir >>> >>> On 1/15/14 9:25 PM, David Holmes wrote: >>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> I updated the webrev: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>> >>>>> - I removed the IRIW example in parse3.cpp >>>>> - I adapted the comments not to point to that comment, and to >>>>> reflect the new flagging. Also I mention that we support the >>>>> volatile constructor issue, but that it's not standard. >>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>> I also think it's better to separate these this way. >>>> >>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>> declaration and all uses to be guarded by ifdef PPC64 too >>>> please. >>>> >>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>> comment doesn't make much sense to me and refers to >>>> ppc specific stuff in a shared file: >>>> >>>> if (is_volatile) { >>>> ! if (!is_store) { >>>> insert_mem_bar(Op_MemBarAcquire); >>>> ! } else { >>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>> insert_mem_bar(Op_MemBarVolatile); >>>> + #endif >>>> + } >>>> >>>> I don't think the comment is needed. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks for your comments! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>> Independent Reads of Independent Writes >>>>> >>>>> Hi Goetz, >>>>> >>>>> Sorry for the delay in getting back to this. >>>>> >>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>> specifically it is >>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>> the commentary excessive, particularly for shared code. In particular >>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>> explanation and I don't think we need it to that level of detail. >>>>> Seems >>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>> >>>>> The changes related to volatile writes in the constructor, as >>>>> discussed >>>>> are not required by the Java Memory Model. If you want to keep these >>>>> then I think they should all be guarded with PPC64 because it is not >>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>> PPC64 porters. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>> this version. >>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>> I also based the webrev on the latest version of the stage repo. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lindenmaier, Goetz >>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>> To: David Holmes >>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi David, >>>>>> >>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>> not >>>>>>> required to pass. >>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>> worked >>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>> it by >>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>> part is >>>>>> not that performance relevant. >>>>>> >>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>> think >>>>>> I added a compile-time guard in this new webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>> several double negations I don't like, (#ifNdef >>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>> but this way I only have to change the ppc platform. >>>>>> >>>>>> Best regards, >>>>>> Goetz >>>>>> >>>>>> P.S.: I will also be available over the Christmas period. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>> emails. >>>>>> >>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>> settled. >>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>> >>>>>>> About our change: David, the causality is the other way round. >>>>>>> The change is about IRIW. >>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>> >>>>>> This is the part I still have some question marks over as the >>>>>> implications are not nice for performance on non-TSO platforms. >>>>>> But I'm >>>>>> no further along in processing that paper I'm afraid. >>>>>> >>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>> stores. >>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>> constructor tests. >>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>> after stores >>>>>>> to pass the volatile constructor tests. >>>>>> >>>>>> So we can at least undo #4 now we have established those tests >>>>>> were not >>>>>> required to pass. >>>>>> >>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>> order >>>>>>> instructions are not as find-granular as the >>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>> The only instruction >>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>> therefore the >>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>> proper representation >>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>> it's pointless >>>>>>> anyways. >>>>>>> >>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>> I'd be happy to add a property >>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>> >>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>> think >>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>> based not architecture based) as that will allows for turning this >>>>>> on/off for any architecture for testing purposes. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>> Or also >>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> TL;DR version: >>>>>>> >>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>> constructor-barrier >>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>> *may* >>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>> ensure >>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>> invalid >>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>> need it >>>>>>> due to other factors). >>>>>>> >>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>> term :) >>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>> >>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>> visible to >>>>>>> all other hardware threads at the same time point; these >>>>>>> architectures >>>>>>> are not multiple-copy atomic." >>>>>>> >>>>>>> This is the visibility issue that I referred to and affects both >>>>>>> ARM and >>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>> current issue is what you wrote below: >>>>>>> >>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>> > remove the sync instruction from behind stores >>>>>>> (parse3.cpp:320) >>>>>>> > and place it before loads. >>>>>>> >>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>> after >>>>>>> the store then you have to do something around the loads to get the >>>>>>> same >>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>> load - >>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>> clearer. >>>>>>> >>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>> variables. You now want to customize that but not all the requisite >>>>>>> hooks are present. It would be better if volatile_load and >>>>>>> volatile_store were factored out so that they could be >>>>>>> implemented as >>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>> hooks >>>>>>> that could then be customized per platform. Otherwise you need >>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>> >>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>> this >>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>> abstractions are a confused mess in my opinion. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>> >>>>>>>> I did not yet add the >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> or >>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>> >>>>>>>> >>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>> I feel not in the position to contribute substantially. >>>>>>>> >>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>> >>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>> store >>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>> (volatile store in constructor). >>>>>>>> >>>>>>>> >>>>>>>> @David >>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>> taskqueue problem yet, >>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>> continuous. >>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>> issue. >>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>> you >>>>>>>> have objections, you should at least give the draft of a better >>>>>>>> solution, >>>>>>>> we would volunteer to implement and test it. >>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>> issues. >>>>>>>> >>>>>>>> @David >>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>> and >>>>>>>>> can't find any reference to it. >>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>> ARM and >>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>> Work-Stealing for >>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>> taskqueue problem. >>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>> >>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>> used 'read' >>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>> above). >>>>>>>> >>>>>>>> Best regards and thanks for all your involvements, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> -- Volatile in constuctor >>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>> missing constructor barrier. >>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>> processors >>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>> Aleksey!) >>>>>>>> >>>>>>>> And see follow ups - the tests are invalid. >>>>>>>> >>>>>>>>> -- IRIW issue >>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>> a few >>>>>>>>>> moments thought. >>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>> problem yet, >>>>>>>>> and that's being discussed now for almost a year. >>>>>>>> >>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>> continuous. >>>>>>>> >>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>> different?) >>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>> I contributed a >>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>> nice, I admit. >>>>>>>>> (I don't really know about ARM, though). >>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>> are evaluated >>>>>>>>> by the C-compiler I'm happy. >>>>>>>>> >>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>> problem >>>>>>>>> is that >>>>>>>>> store >>>>>>>>> sync >>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>> only >>>>>>>>> sync >>>>>>>>> load >>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>> pass that test. >>>>>>>> >>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>> term and >>>>>>>> can't find any reference to it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> The JMM is fine. And >>>>>>>>> store >>>>>>>>> MemBarVolatile >>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>> that >>>>>>>>> do what is required. >>>>>>>>> >>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi everybody, >>>>>>>>>> >>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>> >>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>> initializing >>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>> Shipilev >>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>> Also, concurrency torture tests >>>>>>>>>> LongVolatileTest >>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>> will fail. >>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>> volatile field would be >>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>> AtomicInteger.) >>>>>>>>> >>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>> volatiles do >>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>> that >>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>> Aleksey >>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>> missing constructor barrier. >>>>>>>>> >>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>> heavyweight >>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>> don't >>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>> >>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>> OrderAccess operations >>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>> account >>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>> different platforms >>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>> An example: >>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>> this: >>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>> Assembler::StoreStore) >>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>> Just doing what is required. >>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>> fine grained operations: >>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>> are more (too) powerful, >>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>> can not implement >>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>> >>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>> issue. >>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>> read >>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>> >>>>>>>>>> I would propose to guard the code by >>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>> independent? >>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>> >>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>> few >>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>> will >>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>> moment. The >>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>> requirements for >>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>> are not >>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>> store >>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>> of the >>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>> software >>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>> don't have >>>>>>>>> that on ppc!) >>>>>>>>> >>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>> I will >>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -- Other ports: >>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>> it might >>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>> them). >>>>>>>>>> >>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>> can >>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>> way :) >>>>>>>>>> >>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>> >>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>> fix an >>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>> IRIW >>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>> doing the >>>>>>>>>> load. >>>>>>>>>> >>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>> would be >>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>> performance >>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>> that >>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>> this is >>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>> with the >>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>> the >>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>> properties >>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>> on a >>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>> reduce >>>>>>>>>> to a no-op. >>>>>>>>>> >>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>> under >>>>>>>>>> the JMM. >>>>>>>>>> >>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>> current >>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>> is set >>>>>>>>>>> depending on platform: >>>>>>>>>>> >>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> or similar to what we use now: >>>>>>>>>>> >>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> >>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>> Java >>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>> explicitly >>>>>>>>>> like this. >>>>>>>>>> >>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>> there >>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>> defines? >>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>> David? >>>>>>>>>> >>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>> inside else {}. >>>>>>>>>>> >>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>> specific which >>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>> #ifdefs. >>>>>>>>>>> >>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>> >>>>>>>>>>> if (is_vol) { >>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>> #else >>>>>>>>>>> if (is_field) { >>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>> volatile field >>>>>>>>>>> (PPC64). >>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>> } >>>>>>>>>>> #endif >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>> the torture test suite: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>> >>>>>>>>>>>> Example: >>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>> >>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>> >>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>> is only >>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>> threads >>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>> >>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>> >>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>> fields >>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>> published. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>> seems too >>>>>>>>>>>> strong. >>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>> suffice. >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> From volker.simonis at gmail.com Thu Jan 16 01:38:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 10:38:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis wrote: > > > > On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > >> On 15/01/2014 06:24, David Holmes wrote: >> >>> >>> I'm not a fan of runtime checks of this kind though if it is only a very >>> samll number of values it might be okay. >>> >>> Another option would be to make those classes into "templates" as done >>> with Version.java.template and substitute the right values at build time. >>> >>> But I'll let Alan and net-dev folk come back with their preferred >>> technique for this. >>> >>> I plan to spend time on Volker's webrev later in the week (just too >> busy with other things right now). For the translation issue then it's an >> oversight in the original implementation, it just hasn't come up before (to >> my knowledge anyway). The simplest solution here maybe to to just move them >> to sun.net.ch.Net and have them initialized to their native value. > > > Do you mean sun.nio.ch.Net right? > > Do you propose to completely remove the definitions of the POLL constants > from: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java > src/solaris/classes/sun/nio/ch/Port.java > > and replace all their usages by Net.POLL* ? > > Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the static initializer of IOUtil based on "os.name" or do you prefer to have native methods which return the right constants? Regards, Volker > In general then I'm not too concerned about that one, it's the changes to >> support async close on AIX that are leaping out at me. >> >> -Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140116/cacb3907/attachment.html From Alan.Bateman at oracle.com Thu Jan 16 02:05:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 10:05:44 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: <52D7AEF8.8090502@oracle.com> On 16/01/2014 09:38, Volker Simonis wrote: > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static > initializer of IOUtil based on "os.name " or do you > prefer to have native methods which return the right constants? I have a small preference for sun.nio.ch.Net because these constants are used with Net.poll. Would you be open to separating this one from the AIX changes? The reason is that it isn't AIX specific, rather just an oversight that hasn't been an issue because it doesn't impact other platforms. Using os.name initially would be okay although we could change that over time. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140116/0bb0612a/attachment.html From volker.simonis at gmail.com Thu Jan 16 02:34:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 11:34:03 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D7AEF8.8090502@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman wrote: > On 16/01/2014 09:38, Volker Simonis wrote: > > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static initializer > of IOUtil based on "os.name" or do you prefer to have native methods which > return the right constants? > > I have a small preference for sun.nio.ch.Net because these constants are > used with Net.poll. I just thought because poll is more file-descriptor oriented and not network specific. And the constants are also used for example in: src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: src/solaris/classes/sun/nio/ch/sctp/Sctp* src/solaris/classes/sun/nio/ch/Port.java But actually I have no prefernece here so I can put them just as well to sun.nio.ch.Net > Would you be open to separating this one from the AIX > changes? The reason is that it isn't AIX specific, rather just an oversight > that hasn't been an issue because it doesn't impact other platforms. Sure, no problem. Although I still would like to push this to ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where we really need it. Anyway, the current plan is to merge ppc-aix-port/stage-9 into jdk9 mainline by the end of January and ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would that be ok? > Using > os.name initially would be okay although we could change that over time. I've already written the native methods:) > > -Alan From Alan.Bateman at oracle.com Thu Jan 16 08:51:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 16:51:55 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: <52D80E2B.5000608@oracle.com> On 16/01/2014 10:34, Volker Simonis wrote: > : > I just thought because poll is more file-descriptor oriented and not > network specific. And the constants are also used for example in: > > src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: > src/solaris/classes/sun/nio/ch/sctp/Sctp* > src/solaris/classes/sun/nio/ch/Port.java > > But actually I have no prefernece here so I can put them just as well > to sun.nio.ch.Net It's not used for anything except sockets here (there aren't any selectable channels that aren't also network channels). So I think sun.nio.ch.Net is marginly cleaner here. > : > > Sure, no problem. Although I still would like to push this to > ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where > we really need it. Anyway, the current plan is to merge > ppc-aix-port/stage-9 into jdk9 mainline by the end of January and > ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would > that be ok? > I see you've created a bug for this. I guess it's okay if comes via the ppc port although would still be good to get it into jdk9/dev early as it impacts all platforms. -Alan. From vladimir.kozlov at oracle.com Thu Jan 16 10:15:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jan 2014 10:15:39 -0800 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <52D76E6F.8070504@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> Message-ID: <52D821CB.6020207@oracle.com> Changes are in C++ Interpreter so it does not affect Oracle VM. But David has point here. I would like to hear the explanation too. BTW, I see that for ppc64: src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); as result write_memory_serialize_page() is used in ThreadStateTransition::transition(). Is it not enough on PPC64? Thanks, Vladimir On 1/15/14 9:30 PM, David Holmes wrote: > Can I get some response on this please - specifically the redundancy wrt > IRT_ENTRY actions. > > Thanks, > David > > On 20/12/2013 11:55 AM, David Holmes wrote: >> Still catching up ... >> >> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> this change adds StoreStore barriers after object initialization and >>> after constructor calls in the C++ interpreter. This assures no >>> uninitialized >>> objects or final fields are visible. >>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >> >> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >> thread state transitions that already include a full "fence" so the >> storestore barriers are redundant in those cases. >> >> The fastpath _new storestore seems okay. >> >> I don't know how handle_return gets used to know if it is reasonable or >> not. >> >> I was trying, unsuccessfully, to examine the same code in the >> templateInterpreter to see how it handles these cases as it naturally >> has the same object-initialization-safety requirements (though these can >> be handled in a number of different ways other than an unconditional >> storestore barrier at the end of the initialization and construction >> phases. >> >> David >> ----- >> >>> Please review and test this change. >>> >>> Best regards, >>> Goetz. >>> From philip.race at oracle.com Thu Jan 16 10:53:09 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 16 Jan 2014 10:53:09 -0800 Subject: [OpenJDK 2D-Dev] RFR(S): JDK-8031134 : PPC64: implement printing on AIX In-Reply-To: References: Message-ID: <52D82A95.7030803@oracle.com> Hello Volker, Interesting that all this is needed. How has AIX got by before ? Is this taken from an existing IBM port or did you write this yourself ? I'd hope you are getting help directly from IBM in this area. I suppose that if CUPS is configured and running it'll take precedence over these as it does for the other cases. Someone with AIX should test that at some point as its the only way to know for sure that that works. I'd hoped that AIX would be able to fit into either the BSD or SysV printing mold but it seems like its got its own special commands - lsallq is a new one on me and looks like an AIX special - the "-W" arg to lpstat is completely different than what it means on OS X or Linux ! and there's the oddity that it doesn't expect spaces between the flag and the value .. so I think your approach is the best one. A few specific comments :- } else if (aixPrinterEnumerator.equalsIgnoreCase("lsallq")) { 144 aix_defaultPrinterEnumeration = aix_lsallq; 145 } this code seems redundant since its just reasserting the default unless you intend that this be something that can change multiple times but I'd advise against that and anyway its in static block so that won't happen .. I see you defined 167 static boolean isAIX( ) { 168 return osname.equals("AIX"); 169 } 170 so why are you using this here :- 136 if (osname.equals("AIX")) { instead of calling isAIX() as you do elsewhere ? ... } else if (names.length != 1) { // No default printer found In the other cases we chose to nominate the 1st printer as the default. This seemed a better choice than making apps deal with a list of installed printers but no default. Not sure what problems you might encounter with this (if any). If the situation never occurs its not an issue. -phil. On 1/16/14 12:08 AM, Volker Simonis wrote: > Resending one more time to 2d-dev upon request: > > Hi, > > could somebody please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8031134/ > > It's the straight forward implementation of the basic printing > infrastructure on AIX and shouldn't have any impact on the existing > platforms. As always, this change is intended for the > http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. > > Thank you and best regards, > Volker From david.holmes at oracle.com Thu Jan 16 18:21:11 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jan 2014 12:21:11 +1000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <52D821CB.6020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> Message-ID: <52D89397.2030903@oracle.com> On 17/01/2014 4:15 AM, Vladimir Kozlov wrote: > Changes are in C++ Interpreter so it does not affect Oracle VM. > But David has point here. I would like to hear the explanation too. > > BTW, I see that for ppc64: > > src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); > > as result write_memory_serialize_page() is used in > ThreadStateTransition::transition(). > > Is it not enough on PPC64? You would need to consult a PPC64+linux expert to be certain but what I was basically told is that the serialization page mechanism is only guaranteed to work for TSO systems. David ----- > Thanks, > Vladimir > > On 1/15/14 9:30 PM, David Holmes wrote: >> Can I get some response on this please - specifically the redundancy wrt >> IRT_ENTRY actions. >> >> Thanks, >> David >> >> On 20/12/2013 11:55 AM, David Holmes wrote: >>> Still catching up ... >>> >>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> this change adds StoreStore barriers after object initialization and >>>> after constructor calls in the C++ interpreter. This assures no >>>> uninitialized >>>> objects or final fields are visible. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >>> >>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >>> thread state transitions that already include a full "fence" so the >>> storestore barriers are redundant in those cases. >>> >>> The fastpath _new storestore seems okay. >>> >>> I don't know how handle_return gets used to know if it is reasonable or >>> not. >>> >>> I was trying, unsuccessfully, to examine the same code in the >>> templateInterpreter to see how it handles these cases as it naturally >>> has the same object-initialization-safety requirements (though these can >>> be handled in a number of different ways other than an unconditional >>> storestore barrier at the end of the initialization and construction >>> phases. >>> >>> David >>> ----- >>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz. >>>> From goetz.lindenmaier at sap.com Fri Jan 17 00:39:05 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Jan 2014 08:39:05 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D7A0A9.6070208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> Hi, I tried to come up with a webrev that implements the change as proposed in your mails: http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use support_IRIW_for_not_multiple_copy_atomic_cpu. I left the definition and handling of _wrote_volatile in the code, without any protection. I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , and put it on one line. I removed the comment in library_call.cpp. I also removed the sentence " Solution: implement volatile read as sync-load-acquire." from the comments as it's PPC specific. Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these issues in C1 if nobody did it by then. Wrt. to performance: Oracle will soon do heavy testing of the port. If any performance problems arise, we still can add #ifdef PPC64 to circumvent this. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Donnerstag, 16. Januar 2014 10:05 To: Vladimir Kozlov Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: > On 1/16/14 12:34 AM, David Holmes wrote: >> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>> want to keep it this way, it could be useful to have such info on other >>> platforms too. But I would suggest to remove PPC64 comments in >>> parse.hpp. >>> >>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>> which could be checked in all places instead of #ifdef: >> >> I asked for the ifdef some time back as I find it much preferable to >> have this as a build-time construct rather than a >> runtime one. I don't want to have to pay anything for this if we don't >> use it. > > Any decent C++ compiler will optimize expressions with such constants > defined in header files. I insist to avoid #ifdefs in C2 code. I really > don't like the code with #ifdef in unsafe.cpp but I can live with it. If you insist then we may as well do it all the same way. Better to be consistent. My apologies Goetz for wasting your time going back and forth on this. That aside I have a further concern with this IRIW support - it is incomplete as there is no C1 support, as PPC64 isn't using client. If this is going on then we (which probably means the Oracle 'we') need to add the missing C1 code. David ----- > Vladimir > >> >> David >> >>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>> #else >>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>> #endif >>> >>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>> >>> and then: >>> >>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>> oop p = JNIHandles::resolve(obj); \ >>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>> OrderAccess::fence(); \ >>> volatile type_name v = OrderAccess::load_acquire((volatile >>> type_name*)index_oop_from_field_offset_long(p, offset)); >>> >>> And: >>> >>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>> field->is_volatile()) { >>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>> + } >>> >>> And so on. The comments will be needed only in globalDefinitions.hpp >>> >>> The code in parse1.cpp could be put on one line: >>> >>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>> method()->is_initializer()) )) { >>> >>> Thanks, >>> Vladimir >>> >>> On 1/15/14 9:25 PM, David Holmes wrote: >>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> I updated the webrev: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>> >>>>> - I removed the IRIW example in parse3.cpp >>>>> - I adapted the comments not to point to that comment, and to >>>>> reflect the new flagging. Also I mention that we support the >>>>> volatile constructor issue, but that it's not standard. >>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>> I also think it's better to separate these this way. >>>> >>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>> declaration and all uses to be guarded by ifdef PPC64 too >>>> please. >>>> >>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>> comment doesn't make much sense to me and refers to >>>> ppc specific stuff in a shared file: >>>> >>>> if (is_volatile) { >>>> ! if (!is_store) { >>>> insert_mem_bar(Op_MemBarAcquire); >>>> ! } else { >>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>> insert_mem_bar(Op_MemBarVolatile); >>>> + #endif >>>> + } >>>> >>>> I don't think the comment is needed. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks for your comments! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>> Independent Reads of Independent Writes >>>>> >>>>> Hi Goetz, >>>>> >>>>> Sorry for the delay in getting back to this. >>>>> >>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>> specifically it is >>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>> the commentary excessive, particularly for shared code. In particular >>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>> explanation and I don't think we need it to that level of detail. >>>>> Seems >>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>> >>>>> The changes related to volatile writes in the constructor, as >>>>> discussed >>>>> are not required by the Java Memory Model. If you want to keep these >>>>> then I think they should all be guarded with PPC64 because it is not >>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>> PPC64 porters. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>> this version. >>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>> I also based the webrev on the latest version of the stage repo. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lindenmaier, Goetz >>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>> To: David Holmes >>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi David, >>>>>> >>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>> not >>>>>>> required to pass. >>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>> worked >>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>> it by >>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>> part is >>>>>> not that performance relevant. >>>>>> >>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>> think >>>>>> I added a compile-time guard in this new webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>> several double negations I don't like, (#ifNdef >>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>> but this way I only have to change the ppc platform. >>>>>> >>>>>> Best regards, >>>>>> Goetz >>>>>> >>>>>> P.S.: I will also be available over the Christmas period. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>> emails. >>>>>> >>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>> settled. >>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>> >>>>>>> About our change: David, the causality is the other way round. >>>>>>> The change is about IRIW. >>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>> >>>>>> This is the part I still have some question marks over as the >>>>>> implications are not nice for performance on non-TSO platforms. >>>>>> But I'm >>>>>> no further along in processing that paper I'm afraid. >>>>>> >>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>> stores. >>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>> constructor tests. >>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>> after stores >>>>>>> to pass the volatile constructor tests. >>>>>> >>>>>> So we can at least undo #4 now we have established those tests >>>>>> were not >>>>>> required to pass. >>>>>> >>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>> order >>>>>>> instructions are not as find-granular as the >>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>> The only instruction >>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>> therefore the >>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>> proper representation >>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>> it's pointless >>>>>>> anyways. >>>>>>> >>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>> I'd be happy to add a property >>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>> >>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>> think >>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>> based not architecture based) as that will allows for turning this >>>>>> on/off for any architecture for testing purposes. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>> Or also >>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> TL;DR version: >>>>>>> >>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>> constructor-barrier >>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>> *may* >>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>> ensure >>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>> invalid >>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>> need it >>>>>>> due to other factors). >>>>>>> >>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>> term :) >>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>> >>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>> visible to >>>>>>> all other hardware threads at the same time point; these >>>>>>> architectures >>>>>>> are not multiple-copy atomic." >>>>>>> >>>>>>> This is the visibility issue that I referred to and affects both >>>>>>> ARM and >>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>> current issue is what you wrote below: >>>>>>> >>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>> > remove the sync instruction from behind stores >>>>>>> (parse3.cpp:320) >>>>>>> > and place it before loads. >>>>>>> >>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>> after >>>>>>> the store then you have to do something around the loads to get the >>>>>>> same >>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>> load - >>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>> clearer. >>>>>>> >>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>> variables. You now want to customize that but not all the requisite >>>>>>> hooks are present. It would be better if volatile_load and >>>>>>> volatile_store were factored out so that they could be >>>>>>> implemented as >>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>> hooks >>>>>>> that could then be customized per platform. Otherwise you need >>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>> >>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>> this >>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>> abstractions are a confused mess in my opinion. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>> >>>>>>>> I did not yet add the >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> or >>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>> >>>>>>>> >>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>> I feel not in the position to contribute substantially. >>>>>>>> >>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>> >>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>> store >>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>> (volatile store in constructor). >>>>>>>> >>>>>>>> >>>>>>>> @David >>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>> taskqueue problem yet, >>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>> continuous. >>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>> issue. >>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>> you >>>>>>>> have objections, you should at least give the draft of a better >>>>>>>> solution, >>>>>>>> we would volunteer to implement and test it. >>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>> issues. >>>>>>>> >>>>>>>> @David >>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>> and >>>>>>>>> can't find any reference to it. >>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>> ARM and >>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>> Work-Stealing for >>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>> taskqueue problem. >>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>> >>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>> used 'read' >>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>> above). >>>>>>>> >>>>>>>> Best regards and thanks for all your involvements, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> -- Volatile in constuctor >>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>> missing constructor barrier. >>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>> processors >>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>> Aleksey!) >>>>>>>> >>>>>>>> And see follow ups - the tests are invalid. >>>>>>>> >>>>>>>>> -- IRIW issue >>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>> a few >>>>>>>>>> moments thought. >>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>> problem yet, >>>>>>>>> and that's being discussed now for almost a year. >>>>>>>> >>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>> continuous. >>>>>>>> >>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>> different?) >>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>> I contributed a >>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>> nice, I admit. >>>>>>>>> (I don't really know about ARM, though). >>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>> are evaluated >>>>>>>>> by the C-compiler I'm happy. >>>>>>>>> >>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>> problem >>>>>>>>> is that >>>>>>>>> store >>>>>>>>> sync >>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>> only >>>>>>>>> sync >>>>>>>>> load >>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>> pass that test. >>>>>>>> >>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>> term and >>>>>>>> can't find any reference to it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> The JMM is fine. And >>>>>>>>> store >>>>>>>>> MemBarVolatile >>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>> that >>>>>>>>> do what is required. >>>>>>>>> >>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi everybody, >>>>>>>>>> >>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>> >>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>> initializing >>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>> Shipilev >>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>> Also, concurrency torture tests >>>>>>>>>> LongVolatileTest >>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>> will fail. >>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>> volatile field would be >>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>> AtomicInteger.) >>>>>>>>> >>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>> volatiles do >>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>> that >>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>> Aleksey >>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>> missing constructor barrier. >>>>>>>>> >>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>> heavyweight >>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>> don't >>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>> >>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>> OrderAccess operations >>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>> account >>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>> different platforms >>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>> An example: >>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>> this: >>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>> Assembler::StoreStore) >>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>> Just doing what is required. >>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>> fine grained operations: >>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>> are more (too) powerful, >>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>> can not implement >>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>> >>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>> issue. >>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>> read >>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>> >>>>>>>>>> I would propose to guard the code by >>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>> independent? >>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>> >>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>> few >>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>> will >>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>> moment. The >>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>> requirements for >>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>> are not >>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>> store >>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>> of the >>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>> software >>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>> don't have >>>>>>>>> that on ppc!) >>>>>>>>> >>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>> I will >>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -- Other ports: >>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>> it might >>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>> them). >>>>>>>>>> >>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>> can >>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>> way :) >>>>>>>>>> >>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>> >>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>> fix an >>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>> IRIW >>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>> doing the >>>>>>>>>> load. >>>>>>>>>> >>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>> would be >>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>> performance >>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>> that >>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>> this is >>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>> with the >>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>> the >>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>> properties >>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>> on a >>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>> reduce >>>>>>>>>> to a no-op. >>>>>>>>>> >>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>> under >>>>>>>>>> the JMM. >>>>>>>>>> >>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>> current >>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>> is set >>>>>>>>>>> depending on platform: >>>>>>>>>>> >>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> or similar to what we use now: >>>>>>>>>>> >>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> >>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>> Java >>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>> explicitly >>>>>>>>>> like this. >>>>>>>>>> >>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>> there >>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>> defines? >>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>> David? >>>>>>>>>> >>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>> inside else {}. >>>>>>>>>>> >>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>> specific which >>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>> #ifdefs. >>>>>>>>>>> >>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>> >>>>>>>>>>> if (is_vol) { >>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>> #else >>>>>>>>>>> if (is_field) { >>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>> volatile field >>>>>>>>>>> (PPC64). >>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>> } >>>>>>>>>>> #endif >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>> the torture test suite: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>> >>>>>>>>>>>> Example: >>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>> >>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>> >>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>> is only >>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>> threads >>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>> >>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>> >>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>> fields >>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>> published. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>> seems too >>>>>>>>>>>> strong. >>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>> suffice. >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> From Alan.Bateman at oracle.com Fri Jan 17 01:48:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 09:48:46 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: <52D58C55.6070004@oracle.com> Message-ID: <52D8FC7E.5080908@oracle.com> On 15/01/2014 16:42, Volker Simonis wrote: > Hi Alan, > > thanks for the suggestion. That's fine for me. I've copied the empty > SCTP stubs from the macosx to the aix directory as well and updated > the make file accordingly (in the patch for "8031581: PPC64: Addons > and fixes for AIX to pass the jdk regression tests"). > > Therefore, the changes to the three tests: > > test/com/sun/nio/sctp/SctpChannel/Util.java > test/com/sun/nio/sctp/SctpMultiChannel/Util.java > test/com/sun/nio/sctp/SctpServerChannel/Util.java > > can be considered obsolete. Thanks, I think this makes the most sense. I looked through the rest of this webrev and the update to the tests looks fine. One general comment is that for many of these shell tests (that survive the current effort to replace them) is that we could move the Unix handling into the match any case so that we don't have to list each of Linux, SunOS, Darwin, ... I think this came up when the OS X port was brought in but there wasn't any follow-up on it. I am not suggesting you do this here, it's just a comment as I see same change to so many tests. A minor comment on SBC.java is that it could just catch UnsupportedOperationException on L238, that would avoid needing to check os.name. A really minor comment on the updates to ProblemList.txt is that the JMX test should probably be in the jdk_jmx section (it's just a convention that we've been using, it doesn't of course really matter where tests are listed). -Alan From volker.simonis at gmail.com Fri Jan 17 03:25:24 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 12:25:24 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant Message-ID: Hi, could you please review the following change which makes the various POLL constants used in sun.nio.ch platform dependant: http://cr.openjdk.java.net/~simonis/webrevs/8031997/ These changes are currently targeted for the ppc-aix-port/stage-9 repository but it is planned to merge them soon into jdk9 and jdk8u-dev (for 8u20). Currently, various constants used for the poll/epoll/pollset system calls are defined multiple times as public static final short constants in various Java files: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java src/solaris/classes/sun/nio/ch/Port.java Until now, this has not been a problem because on Linux, Solaris and MacOSX these constants have the same values. However on Windows and AIX they are different. While this hasn't been a problem on Windows either, because as far as I can see, we don't directly use WSAPoll() until now and the POLL constants are only used 'symbolically' on Windows, it became a real problem for the AIX port. To avoid a mapping of the Java constants to the native ones every time we go from Java to Native and back, this change replaces the currently used constants with a single instance of constants which is placed in src/share/classes/sun/nio/ch/Net.java and which are dynamically initialized from native methods with the correct, platfrom-specific values. So this change replaces every occurrence of POLL*, Port.POLL* or AbstractPollArrayWrapper.POLL* in Java code with the corresponding Net.POLL* constants. However, there's one exception to this rule: I haven't changed the POLL constants in src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java. That is not only because DevPollArrayWrapper is Solaris-specific and only used there, but mainly because it uses several, non-standard POLL constants which are only available and meaningful on Solaris and I didn't wanted to bloat the amount of generic constants defined in Net.java. I also didn't updated the constants under src/solaris/demo/jni/Poller because that's a Solaris-specific demo anyway. With Windows, I was a little confused in the beginning. I think until now we don't really use the WSAPoll() functionality there. That's probably because it is only available since Windows Vista / Windows Server 2008 (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx). As far as I understand, the constants are only used "symbolically", to drive the underlying, select() based implementation. I've therefore decided to use the "true" POLL constants on Windows if they are available. Otherwise I'll use the hard-wired (Solaris-based) values. Another Windows peculiarity is the fact that POLLCONN is defined with a value different to all other constants while it equals to POLLOUT on the Unix platforms. I don't know if this is really necessary, but I kept this behaviour in my change. Notice that his change will allow us to directly used the WSAPoll() functionality on Windows in the future. I've compiled and smoke-tested the changes on Linux/x86_64/PPC64, Windows/x86_64, Solaris/SPARC, MacOS X and AIX. On all these platforms they pass all the java/nio JTREG tests in the same way like without this change. This means that on Linux/MacOS they pass all 261/256 tests, on Windows, they pass 258 tests while the following two tests fail: java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java java/nio/channels/DatagramChannel/Promiscuous.java But as I wrote before, these two test also fail without my changes applied, so I'm confident that the failures aren't related to this change. On Solaris, 258 test pass and only the java/nio/charset/Charset/default.sh test fails which isn't related to these changes either. Thank you and best regards, Volker From Alan.Bateman at oracle.com Fri Jan 17 03:44:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 11:44:48 +0000 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: Message-ID: <52D917B0.9090407@oracle.com> On 17/01/2014 11:25, Volker Simonis wrote: > : > > I've compiled and smoke-tested the changes on Linux/x86_64/PPC64, > Windows/x86_64, Solaris/SPARC, MacOS X and AIX. On all these platforms > they pass all the java/nio JTREG tests in the same way like without > this change. This means that on Linux/MacOS they pass all 261/256 > tests, on Windows, they pass 258 tests while the following two tests > fail: > > java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java > java/nio/channels/DatagramChannel/Promiscuous.java > > But as I wrote before, these two test also fail without my changes > applied, so I'm confident that the failures aren't related to this > change. Any chance that this is firewall configuration or VPN that might be cause packets to be dropped? These tests should otherwise pass consistently on all platforms. If you have output from Linux or Solaris or OS X that you could send then it might help to diagnose this. -Alan From goetz.lindenmaier at sap.com Fri Jan 17 05:30:23 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Jan 2014 13:30:23 +0000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <52D821CB.6020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> Hi, I had a look at the first part of this issue: Whether StoreStore is necessary in the interpreter. Let's for now assume the serialization page mechanism works on PPC. In the state transition leaving the VM state, which is executed in the destructor, ThreadStateTransition::transition() is called, which executes if (UseMembar) { OrderAccess::fence(); } else { os::write_memory_serialize_page(thread); } os:: write_memory_serialize_page() can not be considered a proper MemBar, as it only serializes if another thread poisoned the page. Thus it does not qualify to order the initialization and the publishing of the object. You are right, if UseMembar is true, the StoreStore in the interpreter is superfluous. We could guard the StoreStores in the interpreter by !UseMembar. But then again, one is to order the publishing of the thread states, the other to enforce some Java semantics. I don't know whether everybody who changes in one place is aware of both issues. But if you want to, I'll add a !UseMembar in the interpreter. Maybe it would be a good idea to document the double use in interfaceSupport.cpp, too. And maybe add an assertion of some kind. We're digging into the other issue currenty, whether the serialization page works on ppc. We understand your concerns and have no simple answer to it right now. At least, in our VM and in the port there are no known problems with the state transitions. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 16. Januar 2014 19:16 To: David Holmes; Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization Changes are in C++ Interpreter so it does not affect Oracle VM. But David has point here. I would like to hear the explanation too. BTW, I see that for ppc64: src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); as result write_memory_serialize_page() is used in ThreadStateTransition::transition(). Is it not enough on PPC64? Thanks, Vladimir On 1/15/14 9:30 PM, David Holmes wrote: > Can I get some response on this please - specifically the redundancy wrt > IRT_ENTRY actions. > > Thanks, > David > > On 20/12/2013 11:55 AM, David Holmes wrote: >> Still catching up ... >> >> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> this change adds StoreStore barriers after object initialization and >>> after constructor calls in the C++ interpreter. This assures no >>> uninitialized >>> objects or final fields are visible. >>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >> >> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >> thread state transitions that already include a full "fence" so the >> storestore barriers are redundant in those cases. >> >> The fastpath _new storestore seems okay. >> >> I don't know how handle_return gets used to know if it is reasonable or >> not. >> >> I was trying, unsuccessfully, to examine the same code in the >> templateInterpreter to see how it handles these cases as it naturally >> has the same object-initialization-safety requirements (though these can >> be handled in a number of different ways other than an unconditional >> storestore barrier at the end of the initialization and construction >> phases. >> >> David >> ----- >> >>> Please review and test this change. >>> >>> Best regards, >>> Goetz. >>> From volker.simonis at gmail.com Fri Jan 17 05:45:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 14:45:26 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: <52D917B0.9090407@oracle.com> References: <52D917B0.9090407@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 12:44 PM, Alan Bateman wrote: > On 17/01/2014 11:25, Volker Simonis wrote: >> >> : >> >> I've compiled and smoke-tested the changes on Linux/x86_64/PPC64, >> Windows/x86_64, Solaris/SPARC, MacOS X and AIX. On all these platforms >> they pass all the java/nio JTREG tests in the same way like without >> this change. This means that on Linux/MacOS they pass all 261/256 >> tests, on Windows, they pass 258 tests while the following two tests >> fail: >> >> java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java >> java/nio/channels/DatagramChannel/Promiscuous.java >> >> But as I wrote before, these two test also fail without my changes >> applied, so I'm confident that the failures aren't related to this >> change. > > Any chance that this is firewall configuration or VPN that might be cause > packets to be dropped? These tests should otherwise pass consistently on all > platforms. If you have output from Linux or Solaris or OS X that you could > send then it might help to diagnose this. > Yes, you're right - it was because of a "VirtualBox Host-Only Network" network device which seems to fool the test. After I disabled it, all tests passed successfully! And what about the change itself :) > -Alan From volker.simonis at gmail.com Fri Jan 17 06:04:42 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 15:04:42 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: <52D92EBC.1040500@redhat.com> References: <52D92EBC.1040500@redhat.com> Message-ID: On Fri, Jan 17, 2014 at 2:23 PM, Florian Weimer wrote: > On 01/17/2014 12:25 PM, Volker Simonis wrote: >> >> To avoid a mapping of the Java constants to the native ones every time >> we go from Java to Native and back, this change replaces the currently >> used constants with a single instance of constants which is placed in >> src/share/classes/sun/nio/ch/Net.java and which are dynamically >> initialized from native methods with the correct, platfrom-specific >> values. > > > Previously, the constants where inlined at the class file level. Is there a > downside to not doing this? > Hi Florian, I already thought about this. From a performance perspective, I don't think it will have any impact considering that these constants will be used for doing native system calls anyway. It could be of course a problem on AIX (and only there) if third-party code had previously inlined these constants. But as these are internal classes (i.e. sun.nio.ch) which should be only used by the JDK itself, I hope there's not too such much code outside there. Regards, Volker > -- > Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Fri Jan 17 05:23:08 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 17 Jan 2014 14:23:08 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: Message-ID: <52D92EBC.1040500@redhat.com> On 01/17/2014 12:25 PM, Volker Simonis wrote: > To avoid a mapping of the Java constants to the native ones every time > we go from Java to Native and back, this change replaces the currently > used constants with a single instance of constants which is placed in > src/share/classes/sun/nio/ch/Net.java and which are dynamically > initialized from native methods with the correct, platfrom-specific > values. Previously, the constants where inlined at the class file level. Is there a downside to not doing this? -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Fri Jan 17 06:14:12 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 17 Jan 2014 15:14:12 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: <52D92EBC.1040500@redhat.com> Message-ID: <52D93AB4.50402@redhat.com> On 01/17/2014 03:04 PM, Volker Simonis wrote: > On Fri, Jan 17, 2014 at 2:23 PM, Florian Weimer wrote: >> On 01/17/2014 12:25 PM, Volker Simonis wrote: >>> >>> To avoid a mapping of the Java constants to the native ones every time >>> we go from Java to Native and back, this change replaces the currently >>> used constants with a single instance of constants which is placed in >>> src/share/classes/sun/nio/ch/Net.java and which are dynamically >>> initialized from native methods with the correct, platfrom-specific >>> values. >> >> >> Previously, the constants where inlined at the class file level. Is there a >> downside to not doing this? > I already thought about this. From a performance perspective, I don't > think it will have any impact considering that these constants will be > used for doing native system calls anyway. True, and the few extra bytes of class data hopefully don't matter (although they keep adding up). > It could be of course a problem on AIX (and only there) if third-party > code had previously inlined these constants. But as these are internal > classes (i.e. sun.nio.ch) which should be only used by the JDK itself, > I hope there's not too such much code outside there. Some of the classes weren't even public until 8, so this risk is even reduced further. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Fri Jan 17 07:16:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 15:16:54 +0000 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: <52D917B0.9090407@oracle.com> Message-ID: <52D94966.8090407@oracle.com> On 17/01/2014 13:45, Volker Simonis wrote: > : > Yes, you're right - it was because of a "VirtualBox Host-Only Network" > network device which seems to fool the test. After I disabled it, all > tests passed successfully! > > And what about the change itself :) > The change itself looks mostly okay. For naming then I think I would have a slight preference for something like pollinValue to getNatvePollin so that it somewhat consistent with the other places where we do this (like in epoll code with eventSize, eventsOffset, ...). Naming is subjective of course so this isn't a big issue. I suspect you can drop POLLREMOVE, that is only used in the /dev/poll Selector and it has its own definition (and shouldn't be compiled on anything other than Solaris anyway). A minor comment on DatagramChannelImpl, SourceChannelImpl and a few more where the replacing PollArrayWrapper.POLL* with Net.POLL* means it is no longer necessary to split lines (just might be neater to bring these cases back on the one line again). I suspect we will be able to drop the changes to the Windows nio_util.h soon as these older versions of Windows are not long for this world. I assume that by taking on newer VC++ that it won't even be possible to build or run either. -Alan. From Alan.Bateman at oracle.com Fri Jan 17 07:50:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 15:50:27 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: Message-ID: <52D95143.6080601@oracle.com> On 14/01/2014 16:57, Volker Simonis wrote: > Hi, > > could you please review the following change: > > http://cr.openjdk.java.net/~simonis/webrevs/8028537/ > > which, together with the changes from "8031581: PPC64: Addons and fixes for > AIX to pass the jdk regression tests" and "8031134 : PPC64: implement > printing on AIX" enables our our port to pass all but the following 7 jtreg > regression tests on AIX (compared to the Linux/x86_64 baseline from > www.java.net/download/jdk8/testresults/testresults.html?): > I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140117/74d15d2f/attachment.html From volker.simonis at gmail.com Fri Jan 17 09:42:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 18:42:26 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: <52D94966.8090407@oracle.com> References: <52D917B0.9090407@oracle.com> <52D94966.8090407@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 4:16 PM, Alan Bateman wrote: > On 17/01/2014 13:45, Volker Simonis wrote: >> >> : >> Yes, you're right - it was because of a "VirtualBox Host-Only Network" >> network device which seems to fool the test. After I disabled it, all >> tests passed successfully! >> >> And what about the change itself :) >> > The change itself looks mostly okay. > > For naming then I think I would have a slight preference for something like > pollinValue to getNatvePollin so that it somewhat consistent with the other > places where we do this (like in epoll code with eventSize, eventsOffset, > ...). Naming is subjective of course so this isn't a big issue. > Done. > I suspect you can drop POLLREMOVE, that is only used in the /dev/poll > Selector and it has its own definition (and shouldn't be compiled on > anything other than Solaris anyway). > Removed POLLREMOVE from sun.nio.ch.Net. > A minor comment on DatagramChannelImpl, SourceChannelImpl and a few more > where the replacing PollArrayWrapper.POLL* with Net.POLL* means it is no > longer necessary to split lines (just might be neater to bring these cases > back on the one line again). > Done. > I suspect we will be able to drop the changes to the Windows nio_util.h soon > as these older versions of Windows are not long for this world. I assume > that by taking on newer VC++ that it won't even be possible to build or run > either. > We still support Server 2003 :( > -Alan. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031997_2/ Built and tested like before. Everything OK. Is this now ready for push into ppc-aix-port/stage-9? Regards, Volker PS: I've added you as reviewer, but unfortunately after I created the webrev. From volker.simonis at gmail.com Fri Jan 17 10:56:37 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 19:56:37 +0100 Subject: [OpenJDK 2D-Dev] RFR(S): JDK-8031134 : PPC64: implement printing on AIX In-Reply-To: <52D82A95.7030803@oracle.com> References: <52D82A95.7030803@oracle.com> Message-ID: Hi Phil, first of all, thanks a lot for your review. Please find my answers and comments inline: On Thu, Jan 16, 2014 at 7:53 PM, Phil Race wrote: > Hello Volker, > > Interesting that all this is needed. How has AIX got by before ? > Well, there hasn't been AIX support in OpenJDK until now so it obviously didn't work:) > Is this taken from an existing IBM port or did you write this yourself ? > This is from our certified, long running (Java 4,5,6,7), commercial SAP JVM (proudly written by ourselves). > I'd hope you are getting help directly from IBM in this area. > Sometimes:) We're doing the OpenJDK port together with IBM. (That is, we're actually merging our existing, commercial ports in.) > I suppose that if CUPS is configured and running it'll take precedence > over these > as it does for the other cases. Someone with AIX should test that at some > point as > its the only way to know for sure that that works. > There is no such things like CUPS or fontconfig on AIX. Of course somebody may compile, configure and run it by himself. But that's neither the default setting on AIX nor is it supported by IBM. I have no such box and I don't know any customer that would use it. But believe me, our customers are using our implementation since long time - and it is working (even printing). I'd hoped that AIX would be able to fit into either the BSD or SysV > printing mold > but it seems like its got its own special commands > - lsallq is a new one on me and looks like an AIX special > Yes, it's AIX special (from the man page " The lsallq command lists the names of all configured queues contained in the /etc/qconfig file."). However, sometimes it can really save your life, especially if you have costumers which have configured thousands of printers and 'lpstat -p' takes hours to come back (we've seen that!). - the "-W" arg to lpstat is completely different than what it means on OS X > or Linux ! > and there's the oddity that it doesn't expect spaces between the flag and > the value .. > so I think your approach is the best one. > > A few specific comments :- > > } else if (aixPrinterEnumerator.equalsIgnoreCase("lsallq")) { > 144 aix_defaultPrinterEnumeration = aix_lsallq; > 145 } > > this code seems redundant since its just reasserting the default unless > you intend that this be something that can change multiple times but > I'd advise against that and anyway its in static block so that won't > happen .. > We've documented both values for "sun.java2d.print.aix.lpstat" to be able to change the default. So the user should be able to set both values. And no, the value won't be changed anywhere else. I see you defined > > 167 static boolean isAIX( ) { > 168 return osname.equals("AIX"); > 169 } > 170 > > so why are you using this here :- > 136 if (osname.equals("AIX")) { > > instead of calling isAIX() as you do elsewhere ? > Fixed. > ... > > } else if (names.length != 1) { > // No default printer found > > In the other cases we chose to nominate the 1st printer as the default. > This seemed a better choice than making apps deal with a list of > installed printers but no default. Not sure what problems you might > encounter with this (if any). If the situation never occurs its not an > issue. > You're right. This was probably a copy-and-past left over. I think there's no meaningful default printer name on AIX and if 'lpstat -d' doesn't return anything useful then there's probably a problem and we better return 'null'. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031134_2/ Is this now ready for pushing into ppc-aix-port/stage-9? Thank you and best regards, Volker > -phil. > > > On 1/16/14 12:08 AM, Volker Simonis wrote: > >> Resending one more time to 2d-dev upon request: >> >> Hi, >> >> could somebody please review the following small change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031134/ >> >> It's the straight forward implementation of the basic printing >> infrastructure on AIX and shouldn't have any impact on the existing >> platforms. As always, this change is intended for the >> http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. >> >> Thank you and best regards, >> Volker >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140117/b8f379b3/attachment.html From volker.simonis at gmail.com Fri Jan 17 13:10:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 22:10:22 +0100 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: <52D8FC7E.5080908@oracle.com> References: <52D58C55.6070004@oracle.com> <52D8FC7E.5080908@oracle.com> Message-ID: Hi Alan, thanks for looking at this. Please find may comments inline: On Fri, Jan 17, 2014 at 10:48 AM, Alan Bateman wrote: > On 15/01/2014 16:42, Volker Simonis wrote: >> >> Hi Alan, >> >> thanks for the suggestion. That's fine for me. I've copied the empty SCTP >> stubs from the macosx to the aix directory as well and updated the make file >> accordingly (in the patch for "8031581: PPC64: Addons and fixes for AIX to >> pass the jdk regression tests"). >> >> Therefore, the changes to the three tests: >> >> test/com/sun/nio/sctp/SctpChannel/Util.java >> test/com/sun/nio/sctp/SctpMultiChannel/Util.java >> test/com/sun/nio/sctp/SctpServerChannel/Util.java >> >> can be considered obsolete. > > Thanks, I think this makes the most sense. > > I looked through the rest of this webrev and the update to the tests looks > fine. > Great, thanks. > One general comment is that for many of these shell tests (that survive the > current effort to replace them) is that we could move the Unix handling into > the match any case so that we don't have to list each of Linux, SunOS, > Darwin, ... I think this came up when the OS X port was brought in but > there wasn't any follow-up on it. I am not suggesting you do this here, it's > just a comment as I see same change to so many tests. > > A minor comment on SBC.java is that it could just catch > UnsupportedOperationException on L238, that would avoid needing to check > os.name. > I agree, that looks much nicer. Done as requested. > A really minor comment on the updates to ProblemList.txt is that the JMX > test should probably be in the jdk_jmx section (it's just a convention that > we've been using, it doesn't of course really matter where tests are > listed). Done. Moved the excluded tests down to the jdk_jmx section. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8028537_2/ Can I push this now to ppc-aix-port/stage-9? Thank you and best regards, Volker > > -Alan From volker.simonis at gmail.com Fri Jan 17 13:15:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 22:15:08 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > I'd like to review this but I won't have time until later in the week. From > an initial look then there are a few things are not pretty (the changes to > fix the AIX problems with I/O cancellation in particular) and I suspect that > some refactoring is going to be required to handle some of this cleanly. A > minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > -Alan. Just forwarded the following message from another thread here where it belongs: On 17/01/2014 16:57, Alan Bateman wrote: I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too). From Alan.Bateman at oracle.com Fri Jan 17 13:21:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 21:21:26 +0000 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: <52D917B0.9090407@oracle.com> <52D94966.8090407@oracle.com> Message-ID: <52D99ED6.1070806@oracle.com> On 17/01/2014 17:42, Volker Simonis wrote: > : > Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031997_2/ > > Built and tested like before. Everything OK. > > Is this now ready for push into ppc-aix-port/stage-9? > Thanks the updates, this looks good to me. -Alan. From Alan.Bateman at oracle.com Fri Jan 17 13:24:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 21:24:56 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: <52D58C55.6070004@oracle.com> <52D8FC7E.5080908@oracle.com> Message-ID: <52D99FA8.1060108@oracle.com> On 17/01/2014 21:10, Volker Simonis wrote: > : > Done. Moved the excluded tests down to the jdk_jmx section. > > Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8028537_2/ > > Can I push this now to ppc-aix-port/stage-9? > The SBC change looks good. I can't see the move of the excluded test but it's not important anyway. So I think this one is good to go. -Alan. From philip.race at oracle.com Fri Jan 17 15:21:10 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 17 Jan 2014 15:21:10 -0800 Subject: [OpenJDK 2D-Dev] RFR(S): JDK-8031134 : PPC64: implement printing on AIX In-Reply-To: References: <52D82A95.7030803@oracle.com> Message-ID: <52D9BAE6.8000108@oracle.com> Hi, On 1/17/14 10:56 AM, Volker Simonis wrote: > Hi Phil, > > first of all, thanks a lot for your review. Please find my answers and > comments inline: > > On Thu, Jan 16, 2014 at 7:53 PM, Phil Race > wrote: > > Hello Volker, > > Interesting that all this is needed. How has AIX got by before ? > > > Well, there hasn't been AIX support in OpenJDK until now so it > obviously didn't work:) I meant the IBM JDK. > > Is this taken from an existing IBM port or did you write this > yourself ? > > > This is from our certified, long running (Java 4,5,6,7), commercial > SAP JVM (proudly written by ourselves). Got it. Still if IBM have something else in this area they should speak up ! > > I'd hope you are getting help directly from IBM in this area. > > > Sometimes:) We're doing the OpenJDK port together with IBM. (That is, > we're actually merging our existing, commercial ports in.) > > I suppose that if CUPS is configured and running it'll take > precedence over these > as it does for the other cases. Someone with AIX should test that > at some point as > its the only way to know for sure that that works. > > > There is no such things like CUPS or fontconfig on AIX. Of course > somebody may compile, configure and run it by himself. But that's > neither the default setting on AIX nor is it supported by IBM. I have > no such box and I don't know any customer that would use it. Hmm google 'cups aix' suggests it does exist and get used but it may not be supported .. > > But believe me, our customers are using our implementation since long > time - and it is working (even printing). > > I'd hoped that AIX would be able to fit into either the BSD or > SysV printing mold > but it seems like its got its own special commands > - lsallq is a new one on me and looks like an AIX special > > > Yes, it's AIX special (from the man page " The lsallq command lists > the names of all configured queues contained in the /etc/qconfig > file."). However, sometimes it can really save your life, especially > if you have costumers which have configured thousands of printers and > 'lpstat -p' takes hours to come back (we've seen that!). > > - the "-W" arg to lpstat is completely different than what it > means on OS X or Linux ! > and there's the oddity that it doesn't expect spaces between the > flag and the value .. > so I think your approach is the best one. > > A few specific comments :- > > } else if (aixPrinterEnumerator.equalsIgnoreCase("lsallq")) { > 144 aix_defaultPrinterEnumeration = aix_lsallq; > 145 } > > this code seems redundant since its just reasserting the default > unless > you intend that this be something that can change multiple times but > I'd advise against that and anyway its in static block so that > won't happen .. > > > We've documented both values for "sun.java2d.print.aix.lpstat" to be > able to change the default. So the user should be able to set both > values. And no, the value won't be changed anywhere else. I wasn't saying they can't set both, just that the code to re-assert the hard coded default isn't adding anything so I personally would not add the byte code but its up to you. You can push as is if you like. Your hard coded default is 20 or so lines further up : - private static int aix_defaultPrinterEnumeration = aix_lsallq; > > I see you defined > > 167 static boolean isAIX( ) { > 168 return osname.equals("AIX"); > 169 } > 170 > > so why are you using this here :- > 136 if (osname.equals("AIX")) { > > instead of calling isAIX() as you do elsewhere ? > > > Fixed. > > ... > > } else if (names.length != 1) { > // No default printer found > > In the other cases we chose to nominate the 1st printer as the > default. > This seemed a better choice than making apps deal with a list of > installed printers but no default. Not sure what problems you might > encounter with this (if any). If the situation never occurs its > not an issue. > > > You're right. This was probably a copy-and-past left over. > I think there's no meaningful default printer name on AIX and if > 'lpstat -d' doesn't return anything useful then there's probably a > problem and we better return 'null'. > > Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031134_2/ > > > Is this now ready for pushing into ppc-aix-port/stage-9? Yes -phil. > > Thank you and best regards, > Volker > > -phil. > > > On 1/16/14 12:08 AM, Volker Simonis wrote: > > Resending one more time to 2d-dev upon request: > > Hi, > > could somebody please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8031134/ > > > It's the straight forward implementation of the basic printing > infrastructure on AIX and shouldn't have any impact on the > existing > platforms. As always, this change is intended for the > http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. > > Thank you and best regards, > Volker > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140117/611ddec0/attachment-0001.html From vladimir.kozlov at oracle.com Fri Jan 17 17:05:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jan 2014 17:05:35 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> Message-ID: <52D9D35F.2050501@oracle.com> Goetz, I asked to remove both comments in parse.hpp, comments in parse1.cpp and parse3.cpp is enough. It should be similar to _wrote_final: bool _wrote_volatile; // Did we write a final field? I think the next comment in parse3.cpp should be modified: + // But remember we wrote a volatile field so that a barrier can be issued + // in constructors. See do_exits() in parse1.cpp. // Remember we wrote a volatile field. // For not multiple copy atomic cpu (ppc64) a barrier should be issued // in constructors which have such stores. See do_exits() in parse1.cpp. Thanks, Vladimir On 1/17/14 12:39 AM, Lindenmaier, Goetz wrote: > Hi, > > I tried to come up with a webrev that implements the change as proposed in > your mails: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > > Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use > support_IRIW_for_not_multiple_copy_atomic_cpu. > > I left the definition and handling of _wrote_volatile in the code, without > any protection. > I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , > and put it on one line. > > I removed the comment in library_call.cpp. > I also removed the sentence " Solution: implement volatile read as sync-load-acquire." > from the comments as it's PPC specific. > > Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these > issues in C1 if nobody did it by then. > > Wrt. to performance: Oracle will soon do heavy testing of the port. If any > performance problems arise, we still can add #ifdef PPC64 to circumvent this. > > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 16. Januar 2014 10:05 > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >> On 1/16/14 12:34 AM, David Holmes wrote: >>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>> want to keep it this way, it could be useful to have such info on other >>>> platforms too. But I would suggest to remove PPC64 comments in >>>> parse.hpp. >>>> >>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>> which could be checked in all places instead of #ifdef: >>> >>> I asked for the ifdef some time back as I find it much preferable to >>> have this as a build-time construct rather than a >>> runtime one. I don't want to have to pay anything for this if we don't >>> use it. >> >> Any decent C++ compiler will optimize expressions with such constants >> defined in header files. I insist to avoid #ifdefs in C2 code. I really >> don't like the code with #ifdef in unsafe.cpp but I can live with it. > > If you insist then we may as well do it all the same way. Better to be > consistent. > > My apologies Goetz for wasting your time going back and forth on this. > > That aside I have a further concern with this IRIW support - it is > incomplete as there is no C1 support, as PPC64 isn't using client. If > this is going on then we (which probably means the Oracle 'we') need to > add the missing C1 code. > > David > ----- > >> Vladimir >> >>> >>> David >>> >>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>> #else >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>> #endif >>>> >>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>> >>>> and then: >>>> >>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>> oop p = JNIHandles::resolve(obj); \ >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>> OrderAccess::fence(); \ >>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>> >>>> And: >>>> >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>> field->is_volatile()) { >>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>> + } >>>> >>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>> >>>> The code in parse1.cpp could be put on one line: >>>> >>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>> method()->is_initializer()) )) { >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> I updated the webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> >>>>>> - I removed the IRIW example in parse3.cpp >>>>>> - I adapted the comments not to point to that comment, and to >>>>>> reflect the new flagging. Also I mention that we support the >>>>>> volatile constructor issue, but that it's not standard. >>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>> I also think it's better to separate these this way. >>>>> >>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>> please. >>>>> >>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>> comment doesn't make much sense to me and refers to >>>>> ppc specific stuff in a shared file: >>>>> >>>>> if (is_volatile) { >>>>> ! if (!is_store) { >>>>> insert_mem_bar(Op_MemBarAcquire); >>>>> ! } else { >>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>> insert_mem_bar(Op_MemBarVolatile); >>>>> + #endif >>>>> + } >>>>> >>>>> I don't think the comment is needed. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks for your comments! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Sorry for the delay in getting back to this. >>>>>> >>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>> specifically it is >>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>> the commentary excessive, particularly for shared code. In particular >>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>> explanation and I don't think we need it to that level of detail. >>>>>> Seems >>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>> >>>>>> The changes related to volatile writes in the constructor, as >>>>>> discussed >>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>> PPC64 porters. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>> this version. >>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lindenmaier, Goetz >>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>> To: David Holmes >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>> not >>>>>>>> required to pass. >>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>> worked >>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>> it by >>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>> part is >>>>>>> not that performance relevant. >>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>> I added a compile-time guard in this new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>> several double negations I don't like, (#ifNdef >>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>> but this way I only have to change the ppc platform. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>> emails. >>>>>>> >>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>> settled. >>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>> >>>>>>>> About our change: David, the causality is the other way round. >>>>>>>> The change is about IRIW. >>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>> >>>>>>> This is the part I still have some question marks over as the >>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>> But I'm >>>>>>> no further along in processing that paper I'm afraid. >>>>>>> >>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>> stores. >>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>> constructor tests. >>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>> after stores >>>>>>>> to pass the volatile constructor tests. >>>>>>> >>>>>>> So we can at least undo #4 now we have established those tests >>>>>>> were not >>>>>>> required to pass. >>>>>>> >>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>> order >>>>>>>> instructions are not as find-granular as the >>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>> The only instruction >>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>> therefore the >>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>> proper representation >>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>> it's pointless >>>>>>>> anyways. >>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>> I'd be happy to add a property >>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>> >>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>> think >>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>> based not architecture based) as that will allows for turning this >>>>>>> on/off for any architecture for testing purposes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>> Or also >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> TL;DR version: >>>>>>>> >>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>> constructor-barrier >>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>> *may* >>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>> ensure >>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>> invalid >>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>> need it >>>>>>>> due to other factors). >>>>>>>> >>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>> term :) >>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>> >>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>> visible to >>>>>>>> all other hardware threads at the same time point; these >>>>>>>> architectures >>>>>>>> are not multiple-copy atomic." >>>>>>>> >>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>> ARM and >>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>> current issue is what you wrote below: >>>>>>>> >>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>> > remove the sync instruction from behind stores >>>>>>>> (parse3.cpp:320) >>>>>>>> > and place it before loads. >>>>>>>> >>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>> after >>>>>>>> the store then you have to do something around the loads to get the >>>>>>>> same >>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>> load - >>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>> clearer. >>>>>>>> >>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>> volatile_store were factored out so that they could be >>>>>>>> implemented as >>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>> hooks >>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>> >>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>> this >>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>> >>>>>>>>> I did not yet add the >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> or >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>> >>>>>>>>> >>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>> >>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>> >>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>> store >>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>> (volatile store in constructor). >>>>>>>>> >>>>>>>>> >>>>>>>>> @David >>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>> issue. >>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>> you >>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>> solution, >>>>>>>>> we would volunteer to implement and test it. >>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> @David >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>> and >>>>>>>>>> can't find any reference to it. >>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>> ARM and >>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>> Work-Stealing for >>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>> taskqueue problem. >>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>> >>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>> used 'read' >>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>> above). >>>>>>>>> >>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>> processors >>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>> Aleksey!) >>>>>>>>> >>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>> >>>>>>>>>> -- IRIW issue >>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>> a few >>>>>>>>>>> moments thought. >>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>> problem yet, >>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>> >>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>> continuous. >>>>>>>>> >>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) >>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>> I contributed a >>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>> nice, I admit. >>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>> are evaluated >>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>> >>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>> problem >>>>>>>>>> is that >>>>>>>>>> store >>>>>>>>>> sync >>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>> only >>>>>>>>>> sync >>>>>>>>>> load >>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>> pass that test. >>>>>>>>> >>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>> term and >>>>>>>>> can't find any reference to it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> The JMM is fine. And >>>>>>>>>> store >>>>>>>>>> MemBarVolatile >>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>> that >>>>>>>>>> do what is required. >>>>>>>>>> >>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>> >>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>> initializing >>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>> Shipilev >>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>> LongVolatileTest >>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>> will fail. >>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>> volatile field would be >>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>> AtomicInteger.) >>>>>>>>>> >>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>> volatiles do >>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>> that >>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>> Aleksey >>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>> missing constructor barrier. >>>>>>>>>> >>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>> heavyweight >>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>> don't >>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>> >>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>> OrderAccess operations >>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>> account >>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>> different platforms >>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>> An example: >>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>> this: >>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>> Just doing what is required. >>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>> fine grained operations: >>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>> are more (too) powerful, >>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>> can not implement >>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>> >>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>> issue. >>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>> read >>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>> >>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>> independent? >>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>> >>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>> few >>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>> will >>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>> moment. The >>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>> requirements for >>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>> are not >>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>> store >>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>> of the >>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>> software >>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>> don't have >>>>>>>>>> that on ppc!) >>>>>>>>>> >>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>> I will >>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -- Other ports: >>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>> it might >>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>> them). >>>>>>>>>>> >>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>> can >>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>> way :) >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>> >>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>> fix an >>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>> IRIW >>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>> doing the >>>>>>>>>>> load. >>>>>>>>>>> >>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>> would be >>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>> performance >>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>> that >>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>> this is >>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>> with the >>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>> the >>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>> properties >>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>> on a >>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>> reduce >>>>>>>>>>> to a no-op. >>>>>>>>>>> >>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>> under >>>>>>>>>>> the JMM. >>>>>>>>>>> >>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>> current >>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>> is set >>>>>>>>>>>> depending on platform: >>>>>>>>>>>> >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>> >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>> Java >>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>> explicitly >>>>>>>>>>> like this. >>>>>>>>>>> >>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>> there >>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>> defines? >>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>> David? >>>>>>>>>>> >>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>> inside else {}. >>>>>>>>>>>> >>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>> specific which >>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>> #ifdefs. >>>>>>>>>>>> >>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>> >>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>> #else >>>>>>>>>>>> if (is_field) { >>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>> volatile field >>>>>>>>>>>> (PPC64). >>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>> } >>>>>>>>>>>> #endif >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> Example: >>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>> >>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>> >>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>> is only >>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>> threads >>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>> >>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>> >>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>> fields >>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>> published. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>> seems too >>>>>>>>>>>>> strong. >>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>> suffice. >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> From goetz.lindenmaier at sap.com Sat Jan 18 02:36:02 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 18 Jan 2014 10:36:02 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52D9D35F.2050501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52D9D35F.2050501@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D566@DEWDFEMB12A.global.corp.sap> Hi, I updated the comments in the webrev accordingly. http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Saturday, January 18, 2014 2:06 AM To: Lindenmaier, Goetz; David Holmes Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Goetz, I asked to remove both comments in parse.hpp, comments in parse1.cpp and parse3.cpp is enough. It should be similar to _wrote_final: bool _wrote_volatile; // Did we write a final field? I think the next comment in parse3.cpp should be modified: + // But remember we wrote a volatile field so that a barrier can be issued + // in constructors. See do_exits() in parse1.cpp. // Remember we wrote a volatile field. // For not multiple copy atomic cpu (ppc64) a barrier should be issued // in constructors which have such stores. See do_exits() in parse1.cpp. Thanks, Vladimir On 1/17/14 12:39 AM, Lindenmaier, Goetz wrote: > Hi, > > I tried to come up with a webrev that implements the change as proposed in > your mails: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > > Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use > support_IRIW_for_not_multiple_copy_atomic_cpu. > > I left the definition and handling of _wrote_volatile in the code, without > any protection. > I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , > and put it on one line. > > I removed the comment in library_call.cpp. > I also removed the sentence " Solution: implement volatile read as sync-load-acquire." > from the comments as it's PPC specific. > > Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these > issues in C1 if nobody did it by then. > > Wrt. to performance: Oracle will soon do heavy testing of the port. If any > performance problems arise, we still can add #ifdef PPC64 to circumvent this. > > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 16. Januar 2014 10:05 > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >> On 1/16/14 12:34 AM, David Holmes wrote: >>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>> want to keep it this way, it could be useful to have such info on other >>>> platforms too. But I would suggest to remove PPC64 comments in >>>> parse.hpp. >>>> >>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>> which could be checked in all places instead of #ifdef: >>> >>> I asked for the ifdef some time back as I find it much preferable to >>> have this as a build-time construct rather than a >>> runtime one. I don't want to have to pay anything for this if we don't >>> use it. >> >> Any decent C++ compiler will optimize expressions with such constants >> defined in header files. I insist to avoid #ifdefs in C2 code. I really >> don't like the code with #ifdef in unsafe.cpp but I can live with it. > > If you insist then we may as well do it all the same way. Better to be > consistent. > > My apologies Goetz for wasting your time going back and forth on this. > > That aside I have a further concern with this IRIW support - it is > incomplete as there is no C1 support, as PPC64 isn't using client. If > this is going on then we (which probably means the Oracle 'we') need to > add the missing C1 code. > > David > ----- > >> Vladimir >> >>> >>> David >>> >>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>> #else >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>> #endif >>>> >>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>> >>>> and then: >>>> >>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>> oop p = JNIHandles::resolve(obj); \ >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>> OrderAccess::fence(); \ >>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>> >>>> And: >>>> >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>> field->is_volatile()) { >>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>> + } >>>> >>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>> >>>> The code in parse1.cpp could be put on one line: >>>> >>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>> method()->is_initializer()) )) { >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> I updated the webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> >>>>>> - I removed the IRIW example in parse3.cpp >>>>>> - I adapted the comments not to point to that comment, and to >>>>>> reflect the new flagging. Also I mention that we support the >>>>>> volatile constructor issue, but that it's not standard. >>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>> I also think it's better to separate these this way. >>>>> >>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>> please. >>>>> >>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>> comment doesn't make much sense to me and refers to >>>>> ppc specific stuff in a shared file: >>>>> >>>>> if (is_volatile) { >>>>> ! if (!is_store) { >>>>> insert_mem_bar(Op_MemBarAcquire); >>>>> ! } else { >>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>> insert_mem_bar(Op_MemBarVolatile); >>>>> + #endif >>>>> + } >>>>> >>>>> I don't think the comment is needed. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks for your comments! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Sorry for the delay in getting back to this. >>>>>> >>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>> specifically it is >>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>> the commentary excessive, particularly for shared code. In particular >>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>> explanation and I don't think we need it to that level of detail. >>>>>> Seems >>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>> >>>>>> The changes related to volatile writes in the constructor, as >>>>>> discussed >>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>> PPC64 porters. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>> this version. >>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lindenmaier, Goetz >>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>> To: David Holmes >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>> not >>>>>>>> required to pass. >>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>> worked >>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>> it by >>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>> part is >>>>>>> not that performance relevant. >>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>> I added a compile-time guard in this new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>> several double negations I don't like, (#ifNdef >>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>> but this way I only have to change the ppc platform. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>> emails. >>>>>>> >>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>> settled. >>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>> >>>>>>>> About our change: David, the causality is the other way round. >>>>>>>> The change is about IRIW. >>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>> >>>>>>> This is the part I still have some question marks over as the >>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>> But I'm >>>>>>> no further along in processing that paper I'm afraid. >>>>>>> >>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>> stores. >>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>> constructor tests. >>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>> after stores >>>>>>>> to pass the volatile constructor tests. >>>>>>> >>>>>>> So we can at least undo #4 now we have established those tests >>>>>>> were not >>>>>>> required to pass. >>>>>>> >>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>> order >>>>>>>> instructions are not as find-granular as the >>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>> The only instruction >>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>> therefore the >>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>> proper representation >>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>> it's pointless >>>>>>>> anyways. >>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>> I'd be happy to add a property >>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>> >>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>> think >>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>> based not architecture based) as that will allows for turning this >>>>>>> on/off for any architecture for testing purposes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>> Or also >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> TL;DR version: >>>>>>>> >>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>> constructor-barrier >>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>> *may* >>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>> ensure >>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>> invalid >>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>> need it >>>>>>>> due to other factors). >>>>>>>> >>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>> term :) >>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>> >>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>> visible to >>>>>>>> all other hardware threads at the same time point; these >>>>>>>> architectures >>>>>>>> are not multiple-copy atomic." >>>>>>>> >>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>> ARM and >>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>> current issue is what you wrote below: >>>>>>>> >>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>> > remove the sync instruction from behind stores >>>>>>>> (parse3.cpp:320) >>>>>>>> > and place it before loads. >>>>>>>> >>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>> after >>>>>>>> the store then you have to do something around the loads to get the >>>>>>>> same >>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>> load - >>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>> clearer. >>>>>>>> >>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>> volatile_store were factored out so that they could be >>>>>>>> implemented as >>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>> hooks >>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>> >>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>> this >>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>> >>>>>>>>> I did not yet add the >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> or >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>> >>>>>>>>> >>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>> >>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>> >>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>> store >>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>> (volatile store in constructor). >>>>>>>>> >>>>>>>>> >>>>>>>>> @David >>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>> issue. >>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>> you >>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>> solution, >>>>>>>>> we would volunteer to implement and test it. >>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> @David >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>> and >>>>>>>>>> can't find any reference to it. >>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>> ARM and >>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>> Work-Stealing for >>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>> taskqueue problem. >>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>> >>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>> used 'read' >>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>> above). >>>>>>>>> >>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>> processors >>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>> Aleksey!) >>>>>>>>> >>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>> >>>>>>>>>> -- IRIW issue >>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>> a few >>>>>>>>>>> moments thought. >>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>> problem yet, >>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>> >>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>> continuous. >>>>>>>>> >>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) >>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>> I contributed a >>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>> nice, I admit. >>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>> are evaluated >>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>> >>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>> problem >>>>>>>>>> is that >>>>>>>>>> store >>>>>>>>>> sync >>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>> only >>>>>>>>>> sync >>>>>>>>>> load >>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>> pass that test. >>>>>>>>> >>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>> term and >>>>>>>>> can't find any reference to it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> The JMM is fine. And >>>>>>>>>> store >>>>>>>>>> MemBarVolatile >>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>> that >>>>>>>>>> do what is required. >>>>>>>>>> >>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>> >>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>> initializing >>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>> Shipilev >>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>> LongVolatileTest >>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>> will fail. >>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>> volatile field would be >>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>> AtomicInteger.) >>>>>>>>>> >>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>> volatiles do >>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>> that >>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>> Aleksey >>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>> missing constructor barrier. >>>>>>>>>> >>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>> heavyweight >>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>> don't >>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>> >>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>> OrderAccess operations >>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>> account >>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>> different platforms >>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>> An example: >>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>> this: >>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>> Just doing what is required. >>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>> fine grained operations: >>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>> are more (too) powerful, >>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>> can not implement >>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>> >>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>> issue. >>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>> read >>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>> >>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>> independent? >>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>> >>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>> few >>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>> will >>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>> moment. The >>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>> requirements for >>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>> are not >>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>> store >>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>> of the >>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>> software >>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>> don't have >>>>>>>>>> that on ppc!) >>>>>>>>>> >>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>> I will >>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -- Other ports: >>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>> it might >>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>> them). >>>>>>>>>>> >>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>> can >>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>> way :) >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>> >>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>> fix an >>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>> IRIW >>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>> doing the >>>>>>>>>>> load. >>>>>>>>>>> >>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>> would be >>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>> performance >>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>> that >>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>> this is >>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>> with the >>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>> the >>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>> properties >>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>> on a >>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>> reduce >>>>>>>>>>> to a no-op. >>>>>>>>>>> >>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>> under >>>>>>>>>>> the JMM. >>>>>>>>>>> >>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>> current >>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>> is set >>>>>>>>>>>> depending on platform: >>>>>>>>>>>> >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>> >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>> Java >>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>> explicitly >>>>>>>>>>> like this. >>>>>>>>>>> >>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>> there >>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>> defines? >>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>> David? >>>>>>>>>>> >>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>> inside else {}. >>>>>>>>>>>> >>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>> specific which >>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>> #ifdefs. >>>>>>>>>>>> >>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>> >>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>> #else >>>>>>>>>>>> if (is_field) { >>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>> volatile field >>>>>>>>>>>> (PPC64). >>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>> } >>>>>>>>>>>> #endif >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> Example: >>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>> >>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>> >>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>> is only >>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>> threads >>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>> >>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>> >>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>> fields >>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>> published. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>> seems too >>>>>>>>>>>>> strong. >>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>> suffice. >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> From vladimir.kozlov at oracle.com Sat Jan 18 09:36:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 18 Jan 2014 09:36:04 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8D566@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52D9D35F.2050501@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D566@DEWDFEMB12A.global.corp.sap> Message-ID: <52DABB84.1090400@oracle.com> Good. Thanks, Vladimir On 1/18/14 2:36 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the comments in the webrev accordingly. > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Saturday, January 18, 2014 2:06 AM > To: Lindenmaier, Goetz; David Holmes > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Goetz, > > I asked to remove both comments in parse.hpp, comments in parse1.cpp and > parse3.cpp is enough. It should be similar to _wrote_final: > > bool _wrote_volatile; // Did we write a final field? > > > I think the next comment in parse3.cpp should be modified: > > + // But remember we wrote a volatile field so that a barrier can be > issued > + // in constructors. See do_exits() in parse1.cpp. > > // Remember we wrote a volatile field. > // For not multiple copy atomic cpu (ppc64) a barrier should be issued > // in constructors which have such stores. See do_exits() in parse1.cpp. > > Thanks, > Vladimir > > On 1/17/14 12:39 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I tried to come up with a webrev that implements the change as proposed in >> your mails: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >> >> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >> support_IRIW_for_not_multiple_copy_atomic_cpu. >> >> I left the definition and handling of _wrote_volatile in the code, without >> any protection. >> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >> and put it on one line. >> >> I removed the comment in library_call.cpp. >> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >> from the comments as it's PPC specific. >> >> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >> issues in C1 if nobody did it by then. >> >> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 16. Januar 2014 10:05 >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>> On 1/16/14 12:34 AM, David Holmes wrote: >>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>> want to keep it this way, it could be useful to have such info on other >>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>> parse.hpp. >>>>> >>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>> which could be checked in all places instead of #ifdef: >>>> >>>> I asked for the ifdef some time back as I find it much preferable to >>>> have this as a build-time construct rather than a >>>> runtime one. I don't want to have to pay anything for this if we don't >>>> use it. >>> >>> Any decent C++ compiler will optimize expressions with such constants >>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >> >> If you insist then we may as well do it all the same way. Better to be >> consistent. >> >> My apologies Goetz for wasting your time going back and forth on this. >> >> That aside I have a further concern with this IRIW support - it is >> incomplete as there is no C1 support, as PPC64 isn't using client. If >> this is going on then we (which probably means the Oracle 'we') need to >> add the missing C1 code. >> >> David >> ----- >> >>> Vladimir >>> >>>> >>>> David >>>> >>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>> #else >>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>> #endif >>>>> >>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>> >>>>> and then: >>>>> >>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>> oop p = JNIHandles::resolve(obj); \ >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>> OrderAccess::fence(); \ >>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>> >>>>> And: >>>>> >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>> field->is_volatile()) { >>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>> + } >>>>> >>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>> >>>>> The code in parse1.cpp could be put on one line: >>>>> >>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>> method()->is_initializer()) )) { >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I updated the webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>> volatile constructor issue, but that it's not standard. >>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>> I also think it's better to separate these this way. >>>>>> >>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>> please. >>>>>> >>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>> comment doesn't make much sense to me and refers to >>>>>> ppc specific stuff in a shared file: >>>>>> >>>>>> if (is_volatile) { >>>>>> ! if (!is_store) { >>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>> ! } else { >>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>> + #endif >>>>>> + } >>>>>> >>>>>> I don't think the comment is needed. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks for your comments! >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> Sorry for the delay in getting back to this. >>>>>>> >>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>> specifically it is >>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>> Seems >>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>> >>>>>>> The changes related to volatile writes in the constructor, as >>>>>>> discussed >>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>> PPC64 porters. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>> this version. >>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lindenmaier, Goetz >>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>> To: David Holmes >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>> not >>>>>>>>> required to pass. >>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>> worked >>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>> it by >>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>> part is >>>>>>>> not that performance relevant. >>>>>>>> >>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>> think >>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>> but this way I only have to change the ppc platform. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz >>>>>>>> >>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>> emails. >>>>>>>> >>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>> settled. >>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>> >>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>> The change is about IRIW. >>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>> >>>>>>>> This is the part I still have some question marks over as the >>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>> But I'm >>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>> >>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>> stores. >>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>> constructor tests. >>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>> after stores >>>>>>>>> to pass the volatile constructor tests. >>>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>> were not >>>>>>>> required to pass. >>>>>>>> >>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>> order >>>>>>>>> instructions are not as find-granular as the >>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>> The only instruction >>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>> therefore the >>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>> proper representation >>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>> it's pointless >>>>>>>>> anyways. >>>>>>>>> >>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>> I'd be happy to add a property >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>> on/off for any architecture for testing purposes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>> Or also >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> TL;DR version: >>>>>>>>> >>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>> constructor-barrier >>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>> *may* >>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>> ensure >>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>> invalid >>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>> need it >>>>>>>>> due to other factors). >>>>>>>>> >>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>> term :) >>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>> >>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>> visible to >>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>> architectures >>>>>>>>> are not multiple-copy atomic." >>>>>>>>> >>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>> ARM and >>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>> current issue is what you wrote below: >>>>>>>>> >>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>> (parse3.cpp:320) >>>>>>>>> > and place it before loads. >>>>>>>>> >>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>> after >>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>> same >>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>> load - >>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>> clearer. >>>>>>>>> >>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>> implemented as >>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>> hooks >>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>> this >>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>> >>>>>>>>>> I did not yet add the >>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> or >>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>> >>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>> >>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>> store >>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>> (volatile store in constructor). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> @David >>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>> continuous. >>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>> issue. >>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>> you >>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>> solution, >>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>> issues. >>>>>>>>>> >>>>>>>>>> @David >>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>> and >>>>>>>>>>> can't find any reference to it. >>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>> ARM and >>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>> Work-Stealing for >>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>> taskqueue problem. >>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>> >>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>> used 'read' >>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>> above). >>>>>>>>>> >>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>> processors >>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>> Aleksey!) >>>>>>>>>> >>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>> >>>>>>>>>>> -- IRIW issue >>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>> a few >>>>>>>>>>>> moments thought. >>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>> problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>>> >>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>> different?) >>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>> I contributed a >>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>> nice, I admit. >>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>> are evaluated >>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>> >>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>> problem >>>>>>>>>>> is that >>>>>>>>>>> store >>>>>>>>>>> sync >>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>> only >>>>>>>>>>> sync >>>>>>>>>>> load >>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>> pass that test. >>>>>>>>>> >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>> term and >>>>>>>>>> can't find any reference to it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> The JMM is fine. And >>>>>>>>>>> store >>>>>>>>>>> MemBarVolatile >>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>> that >>>>>>>>>>> do what is required. >>>>>>>>>>> >>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi everybody, >>>>>>>>>>>> >>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>> >>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>> initializing >>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>> Shipilev >>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>> will fail. >>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>> volatile field would be >>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>> >>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>> volatiles do >>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>> that >>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>> Aleksey >>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>>> >>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>> heavyweight >>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>> don't >>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>> >>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>> account >>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>> different platforms >>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>> An example: >>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>> this: >>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>> fine grained operations: >>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>> can not implement >>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>> >>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>> issue. >>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>> read >>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>> >>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>> independent? >>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>> >>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>> few >>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>> will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>> moment. The >>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>> requirements for >>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>> are not >>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>> store >>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>> of the >>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>> software >>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>> don't have >>>>>>>>>>> that on ppc!) >>>>>>>>>>> >>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>> I will >>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> -- Other ports: >>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>> it might >>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>> them). >>>>>>>>>>>> >>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>> can >>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>> way :) >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>> >>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>> fix an >>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>> IRIW >>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>> doing the >>>>>>>>>>>> load. >>>>>>>>>>>> >>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>> would be >>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>> performance >>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>> that >>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>> this is >>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>> with the >>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>> the >>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>> properties >>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>> on a >>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>> reduce >>>>>>>>>>>> to a no-op. >>>>>>>>>>>> >>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>> under >>>>>>>>>>>> the JMM. >>>>>>>>>>>> >>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>> current >>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>> is set >>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>> >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>> >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>> Java >>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>> explicitly >>>>>>>>>>>> like this. >>>>>>>>>>>> >>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>> there >>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>> defines? >>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>> David? >>>>>>>>>>>> >>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>> >>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>> specific which >>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>> >>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>> >>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>> #else >>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>> volatile field >>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>> } >>>>>>>>>>>>> #endif >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Example: >>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>> >>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>> is only >>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>> threads >>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>> fields >>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>> published. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>> seems too >>>>>>>>>>>>>> strong. >>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> From david.holmes at oracle.com Sun Jan 19 18:44:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jan 2014 12:44:57 +1000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> Message-ID: <52DC8DA9.2010106@oracle.com> On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote: > Hi, > > I had a look at the first part of this issue: Whether StoreStore > is necessary in the interpreter. Let's for now assume the serialization > page mechanism works on PPC. > > In the state transition leaving the VM state, which is executed in the > destructor, ThreadStateTransition::transition() is called, which executes > if (UseMembar) { > OrderAccess::fence(); > } else { > os::write_memory_serialize_page(thread); > } > > os:: write_memory_serialize_page() can not be considered a proper > MemBar, as it only serializes if another thread poisoned the page. > Thus it does not qualify to order the initialization and the publishing > of the object. > > You are right, if UseMembar is true, the StoreStore in the interpreter > is superfluous. We could guard the StoreStores in the interpreter by > !UseMembar. My understanding, from our existing non-TSO system ports, is that the present assumption is that either: a) you have a TSO system, in which case you are probably using the serialization page, but you don't need any barrier to enforce ordering anyway; or b) you don't have a TSO system, you are using UseMembar==true and so you get a full fence inserted that enforces the ordering anyway. So the ordering requirements are satisfied by piggy-backing on the UseMembar setting that comes from the thread state transition code, which forms part of the "runtime entry" code. That's not to say that you will necessarily find this applied consistently in all places where it might be applied - nor will you necessarily find that this is common knowledge amongst VM engineers. Technically the storeStore barriers could be conditional on !UseMembar but that is redundant in the current usage. > But then again, one is to order the publishing of the thread states, > the other to enforce some Java semantics. I don't know whether everybody > who changes in one place is aware of both issues. But if you want to, > I'll add a !UseMembar in the interpreter. Here are my preferred options in order: 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - rely on the piggy-backing effect. 2. Conditionalize the new storeStore barriers on !UseMembar. This unfortunately penalizes all platforms with a runtime check. 3. Add the storeStores unconditionally. This penalizes platforms that set UseMembar==true as we will now get two fences at runtime. I know we're talking about the interpreter here so performance is not exactly critical, but still ... > Maybe it would be a good idea > to document the double use in interfaceSupport.cpp, too. And maybe > add an assertion of some kind. interfaceSupport doesn't know that other code piggy-backs on the fact state-transitions have full fences when UseMembar is true. If it is documented anywhere it should be in the interpreter (and any other places that makes the same assumption) - something like: // On non-TSO systems there can be additional ordering constraints // between Java-level actions (such as allocation and constructor // invocation) that in principle need explicit memory barriers. // However, on many non-TSO systems the thread-state transition logic // in the IRT_ENTRY code will insert a full fence due to the use of // UseMembar==true, which provides the necessary ordering guarantees. > > We're digging into the other issue currenty, whether the serialization page > works on ppc. We understand your concerns and have no simple answer to > it right now. At least, in our VM and in the port there are no known problems > with the state transitions. Even if the memory serialization page does not work, in a guaranteed sense, on PPC-AIX, it is extremely unlikely that testing would expose this. Also note that the memory serialization page behaviour is more a function of the OS - so it may be that AIX is different to linux in that regard. Cheers, David ----- > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Donnerstag, 16. Januar 2014 19:16 > To: David Holmes; Lindenmaier, Goetz > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' > Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization > > Changes are in C++ Interpreter so it does not affect Oracle VM. > But David has point here. I would like to hear the explanation too. > > BTW, I see that for ppc64: > > src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); > > as result write_memory_serialize_page() is used in > ThreadStateTransition::transition(). > > Is it not enough on PPC64? > > Thanks, > Vladimir > > On 1/15/14 9:30 PM, David Holmes wrote: >> Can I get some response on this please - specifically the redundancy wrt >> IRT_ENTRY actions. >> >> Thanks, >> David >> >> On 20/12/2013 11:55 AM, David Holmes wrote: >>> Still catching up ... >>> >>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> this change adds StoreStore barriers after object initialization and >>>> after constructor calls in the C++ interpreter. This assures no >>>> uninitialized >>>> objects or final fields are visible. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >>> >>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >>> thread state transitions that already include a full "fence" so the >>> storestore barriers are redundant in those cases. >>> >>> The fastpath _new storestore seems okay. >>> >>> I don't know how handle_return gets used to know if it is reasonable or >>> not. >>> >>> I was trying, unsuccessfully, to examine the same code in the >>> templateInterpreter to see how it handles these cases as it naturally >>> has the same object-initialization-safety requirements (though these can >>> be handled in a number of different ways other than an unconditional >>> storestore barrier at the end of the initialization and construction >>> phases. >>> >>> David >>> ----- >>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz. >>>> From volker.simonis at gmail.com Mon Jan 20 00:23:35 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Mon, 20 Jan 2014 08:23:35 +0000 Subject: hg: ppc-aix-port/stage-9/jdk: 8031134: PPC64: implement printing on AIX Message-ID: <20140120082348.0329A625A6@hg.openjdk.java.net> Changeset: e11c60a3eefb Author: simonis Date: 2014-01-20 09:20 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e11c60a3eefb 8031134: PPC64: implement printing on AIX Reviewed-by: prr ! src/solaris/classes/sun/print/UnixPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java From volker.simonis at gmail.com Mon Jan 20 00:27:05 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Mon, 20 Jan 2014 08:27:05 +0000 Subject: hg: ppc-aix-port/stage-9/jdk: 8031997: PPC64: Make the various POLL constants system dependant Message-ID: <20140120082718.8F3FF625A7@hg.openjdk.java.net> Changeset: 4231d71b18cf Author: simonis Date: 2014-01-20 09:24 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/4231d71b18cf 8031997: PPC64: Make the various POLL constants system dependant Reviewed-by: alanb ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! src/aix/classes/sun/nio/ch/AixPollPort.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java ! src/windows/classes/sun/nio/ch/SinkChannelImpl.java ! src/windows/classes/sun/nio/ch/SourceChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c ! src/windows/native/sun/nio/ch/nio_util.h From volker.simonis at gmail.com Mon Jan 20 00:18:33 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Mon, 20 Jan 2014 08:18:33 +0000 Subject: hg: ppc-aix-port/stage-9/jdk: 8028537: PPC64: Updated the JDK regression tests to run on AIX Message-ID: <20140120081918.D1D1D625A4@hg.openjdk.java.net> Changeset: f04b825b1c0c Author: simonis Date: 2014-01-17 21:54 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/f04b825b1c0c 8028537: PPC64: Updated the JDK regression tests to run on AIX Reviewed-by: alanb Contributed-by: luchsh at linux.vnet.ibm.com, spoole at linux.vnet.ibm.com, volker.simonis at gmail.com ! test/ProblemList.txt ! test/com/sun/corba/5036554/TestCorbaBug.sh ! test/com/sun/corba/cachedSocket/7056731.sh ! test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/ShellScaffold.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/Send12k.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/SBC.java ! test/java/nio/file/Files/walkFileTree/find.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatTest.sh ! test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatThreadTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/script/CommonSetup.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh ! test/sun/net/ftp/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/rmi/rmic/newrmic/equivalence/batch.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/KeyStore/DKSTest.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/StorePasswordsByShell.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/tools/common/CommonSetup.sh ! test/sun/tools/jconsole/ResourceCheckTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/Settings.java ! test/tools/launcher/TestHelper.java From volker.simonis at gmail.com Mon Jan 20 01:59:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 10:59:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> I'd like to review this but I won't have time until later in the week. From >> an initial look then there are a few things are not pretty (the changes to >> fix the AIX problems with I/O cancellation in particular) and I suspect that >> some refactoring is going to be required to handle some of this cleanly. A >> minor comment is that bug synopsis doesn't really communicate what these >> changes are about. >> >> -Alan. > > Just forwarded the following message from another thread here where it belongs: > > On 17/01/2014 16:57, Alan Bateman wrote: > > I've finally got to this one. As the event translation issue is now a > separate issue then I've ignored that part. > > I'm not comfortable with the changes to FileDispatcherImpl.c as I > don't think we shouldn't be calling into IO_ or NET_* functions here. > I think I get the issue that you have on AIX (and assume it's the > preClose/dup2 that blocks rather than close) but need a bit of time to > suggest alternatives. It may be that it will require an AIX specific > SocketDispatcher. Do you happen to know which tests fail due to this > part? > > The other changes look okay. There is a typo in the change to > zip_util.c, s/legel/legal/. > > In DatagramChannelImpl.c then you handle connect failing with > EAFNOSUPPORT. I would be tempted to replace the comment to say that it > EAFNOSUPPORT can be ignored on AIX. A minor comment but the > indentation for rv = errno can be fixed (I see the BSD code has it > wrong too). > On 17/01/2014 21:23, Volker Simonis wrote: > > > You're right, one race is with preClose/dup2 but also with other calls > > like read/fcntl/... > > > > There were several tests that failed and once I fixed it they all > > succeeded. But I can recreate some of the failures for you. The > > symptoms are always the same: the VMis locked. If you trigger a stack > > trace you can see that at least on thread is blocked in a I/O > > operation on a file descriptor like fcntl (e.g. for file locking), > > read, etc. while another thread is trying to close that socket. > > > > As it happens, we have some carry over issues from the Mac port, > one of which is that async close of FileChannels will block > indefinitely in dup2 when there is another thread blocked (on > fnctl or reading from a pipe ...). I haven't time time to work on > it but this discussion has reminded me that we need to sort it > out. I've put a preliminary webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/7133499/webrev/ > > The important part is that it's using signal consistently on > Linux/Solaris/OSX so that any blocked threads are interrupted. My > guess is that if NativeThread.c is updated to define a signal on > AIX they this should resolve some of the issues on AIX. > > I would like to see the list of tests failing. If there is an > issue with dup2 with sockets (and OS X doesn't seem to have that > issue) then it will require further work but I would at least > like to start by understanding if this patch will help with the > FileChannel issues. Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and send out a new webrev for the remaining part. I think that the remaining part was more or less reviewed and we can then push it faster. In the mean time, I'll recheck which tests exactly fail with my missing "Async Close AIX FIX" stuff and which of these tests will be fixed by your 7133499 webrev. Maybe we can really get trough with it or with it and a few enhancements. I'll let you know my results later today. By the way, my webrev already contained a AixNativeThread.c implementation in src/aix/native/sun/nio/ch. The only remaining problem I see with this approach is that we would need to downport your 7133499 change to 8u-dev in the 8u20 time frame to make our AIX port work. Would this be OK for you? Regards, Volker From Alan.Bateman at oracle.com Mon Jan 20 03:41:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 11:41:48 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: <52DD0B7C.4090605@oracle.com> On 20/01/2014 09:59, Volker Simonis wrote: > : > Hi Alan, > > yes, that's interesting. Sounds like a very similar problem on Mac. > > I would suggest the following: > > I cut out the "Async Close AIX FIX" stuff from this change (i.e. > "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression > tests" and send out a new webrev for the remaining part. I think that > the remaining part was more or less reviewed and we can then push it > faster. > > In the mean time, I'll recheck which tests exactly fail with my > missing "Async Close AIX FIX" stuff and which of these tests will be > fixed by your 7133499 webrev. Maybe we can really get trough with it > or with it and a few enhancements. I'll let you know my results later > today. By the way, my webrev already contained a AixNativeThread.c > implementation in src/aix/native/sun/nio/ch. > > The only remaining problem I see with this approach is that we would > need to downport your 7133499 change to 8u-dev in the 8u20 time frame > to make our AIX port work. Would this be OK for you? > I'm okay with this plan and if you re-generate the webrev without the async close changes then I can look at it quickly so that you can get it into the stage-9 forest. On 7133499 then it would be a good candidate for 8u-dev too, I don't expect any problems but we will need to get it approved on the jdk8u-dev list. -Alan. From goetz.lindenmaier at sap.com Mon Jan 20 05:26:26 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Jan 2014 13:26:26 +0000 Subject: serialization page mechanism on PPC Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D91E@DEWDFEMB12A.global.corp.sap> Hi Tiago, I have a question regarding the linux implementation on PPC. HotSpot contains a mechanism that forces a thread to enforce memory ordering by using a "serialization page". The idea is that thread t1 who rarely changes a certain field forces another thread t2 to update it's memory state by poisoning a page. I.e.: t1 sets a shared page called serialization page to "READ" and then again to "RW". t2 does a write on this page. If a page fault occurs after t1 changed the state, and assuming that handling this fault forces a memory serialization, this works as a conditional "sync" instruction executed in t2. We use this mechanism in our VM for a long time without problems, but never explored the background of this trick. Now it was questioned while discussing the OpenJDK PPC changes. Do you know whether this works on PPC as it does on x86 etc? Or do you know somebody who can answer this question? Basically it drills down to two questions: - Will t2 execute some os-operation on the write after t1 changed the access rights? - Does this operation force a sync or ptwsync or equivalent? Actually, we also would like to know whether this works on AIX. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140120/75b028e7/attachment.html From goetz.lindenmaier at sap.com Mon Jan 20 05:41:26 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Jan 2014 13:41:26 +0000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <52DC8DA9.2010106@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> <52DC8DA9.2010106@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap> Hi David, I understand your arguments and basically agree with them. If the serialization page does not work on PPC, your solution 1) is best. But I'm not sure why there should be a link between TSO and whether the serialization page trick works. Second depends, as you say, on the OS implementation. I would assume that the write to the serialization page causes the OS to generate a new TLB entry or the like, involving the use of a ptwsync instruction which would be fine. But we are investigating this. We are also experimenting with a small regression test to find out whether the serialization page ever fails. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 20. Januar 2014 03:45 To: Lindenmaier, Goetz; Vladimir Kozlov Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote: > Hi, > > I had a look at the first part of this issue: Whether StoreStore > is necessary in the interpreter. Let's for now assume the serialization > page mechanism works on PPC. > > In the state transition leaving the VM state, which is executed in the > destructor, ThreadStateTransition::transition() is called, which executes > if (UseMembar) { > OrderAccess::fence(); > } else { > os::write_memory_serialize_page(thread); > } > > os:: write_memory_serialize_page() can not be considered a proper > MemBar, as it only serializes if another thread poisoned the page. > Thus it does not qualify to order the initialization and the publishing > of the object. > > You are right, if UseMembar is true, the StoreStore in the interpreter > is superfluous. We could guard the StoreStores in the interpreter by > !UseMembar. My understanding, from our existing non-TSO system ports, is that the present assumption is that either: a) you have a TSO system, in which case you are probably using the serialization page, but you don't need any barrier to enforce ordering anyway; or b) you don't have a TSO system, you are using UseMembar==true and so you get a full fence inserted that enforces the ordering anyway. So the ordering requirements are satisfied by piggy-backing on the UseMembar setting that comes from the thread state transition code, which forms part of the "runtime entry" code. That's not to say that you will necessarily find this applied consistently in all places where it might be applied - nor will you necessarily find that this is common knowledge amongst VM engineers. Technically the storeStore barriers could be conditional on !UseMembar but that is redundant in the current usage. > But then again, one is to order the publishing of the thread states, > the other to enforce some Java semantics. I don't know whether everybody > who changes in one place is aware of both issues. But if you want to, > I'll add a !UseMembar in the interpreter. Here are my preferred options in order: 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - rely on the piggy-backing effect. 2. Conditionalize the new storeStore barriers on !UseMembar. This unfortunately penalizes all platforms with a runtime check. 3. Add the storeStores unconditionally. This penalizes platforms that set UseMembar==true as we will now get two fences at runtime. I know we're talking about the interpreter here so performance is not exactly critical, but still ... > Maybe it would be a good idea > to document the double use in interfaceSupport.cpp, too. And maybe > add an assertion of some kind. interfaceSupport doesn't know that other code piggy-backs on the fact state-transitions have full fences when UseMembar is true. If it is documented anywhere it should be in the interpreter (and any other places that makes the same assumption) - something like: // On non-TSO systems there can be additional ordering constraints // between Java-level actions (such as allocation and constructor // invocation) that in principle need explicit memory barriers. // However, on many non-TSO systems the thread-state transition logic // in the IRT_ENTRY code will insert a full fence due to the use of // UseMembar==true, which provides the necessary ordering guarantees. > > We're digging into the other issue currenty, whether the serialization page > works on ppc. We understand your concerns and have no simple answer to > it right now. At least, in our VM and in the port there are no known problems > with the state transitions. Even if the memory serialization page does not work, in a guaranteed sense, on PPC-AIX, it is extremely unlikely that testing would expose this. Also note that the memory serialization page behaviour is more a function of the OS - so it may be that AIX is different to linux in that regard. Cheers, David ----- > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Donnerstag, 16. Januar 2014 19:16 > To: David Holmes; Lindenmaier, Goetz > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' > Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization > > Changes are in C++ Interpreter so it does not affect Oracle VM. > But David has point here. I would like to hear the explanation too. > > BTW, I see that for ppc64: > > src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); > > as result write_memory_serialize_page() is used in > ThreadStateTransition::transition(). > > Is it not enough on PPC64? > > Thanks, > Vladimir > > On 1/15/14 9:30 PM, David Holmes wrote: >> Can I get some response on this please - specifically the redundancy wrt >> IRT_ENTRY actions. >> >> Thanks, >> David >> >> On 20/12/2013 11:55 AM, David Holmes wrote: >>> Still catching up ... >>> >>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> this change adds StoreStore barriers after object initialization and >>>> after constructor calls in the C++ interpreter. This assures no >>>> uninitialized >>>> objects or final fields are visible. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >>> >>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >>> thread state transitions that already include a full "fence" so the >>> storestore barriers are redundant in those cases. >>> >>> The fastpath _new storestore seems okay. >>> >>> I don't know how handle_return gets used to know if it is reasonable or >>> not. >>> >>> I was trying, unsuccessfully, to examine the same code in the >>> templateInterpreter to see how it handles these cases as it naturally >>> has the same object-initialization-safety requirements (though these can >>> be handled in a number of different ways other than an unconditional >>> storestore barrier at the end of the initialization and construction >>> phases. >>> >>> David >>> ----- >>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz. >>>> From volker.simonis at gmail.com Mon Jan 20 05:45:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 14:45:12 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD0B7C.4090605@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > On 20/01/2014 09:59, Volker Simonis wrote: >> >> : >> Hi Alan, >> >> yes, that's interesting. Sounds like a very similar problem on Mac. >> >> I would suggest the following: >> >> I cut out the "Async Close AIX FIX" stuff from this change (i.e. >> "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression >> tests" and send out a new webrev for the remaining part. I think that >> the remaining part was more or less reviewed and we can then push it >> faster. >> >> In the mean time, I'll recheck which tests exactly fail with my >> missing "Async Close AIX FIX" stuff and which of these tests will be >> fixed by your 7133499 webrev. Maybe we can really get trough with it >> or with it and a few enhancements. I'll let you know my results later >> today. By the way, my webrev already contained a AixNativeThread.c >> implementation in src/aix/native/sun/nio/ch. >> >> The only remaining problem I see with this approach is that we would >> need to downport your 7133499 change to 8u-dev in the 8u20 time frame >> to make our AIX port work. Would this be OK for you? >> > I'm okay with this plan and if you re-generate the webrev without the async > close changes then I can look at it quickly so that you can get it into the > stage-9 forest. > > On 7133499 then it would be a good candidate for 8u-dev too, I don't expect > any problems but we will need to get it approved on the jdk8u-dev list. > > -Alan. Hi everybody, so here's the second version of this webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ The main changes compared to the first webrew are as follows: - the POLL-constants related stuff has been factored out into its own webrev ("8031997: PPC64: Make the various POLL constants system dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). - the "Async close on AIX" workarounds have been taken out as well and will be handled separately (probably together with Alans fix for http://cr.openjdk.java.net/~alanb/7133499/webrev/). - in the remaining files I've applied the changes suggested by Staffan, so I think the changes to the following files can be considered as reviewed: src/share/native/sun/management/DiagnosticCommandImpl.c src/solaris/native/sun/management/OperatingSystemImpl.c src/share/transport/socket/socketTransport.c src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - I've added the following additional files to the change: src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java which are just empty stub implementations of the SCTP classes needed to pass the SCTP jtreg tests. All other changes should be the same like in the first review round. Thanks, Volker From Alan.Bateman at oracle.com Mon Jan 20 07:24:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 15:24:01 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: <52DD3F91.7020202@oracle.com> On 20/01/2014 13:45, Volker Simonis wrote: > : > Hi everybody, > > so here's the second version of this webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ This looks okay to me. The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can be fixed before you push this (no need to generate a few webrev of course). For the JDWP socket transport then it's interesting that shutdown is being used to cause the reader thread to be preempted. That may be useful when it comes to addressing the bigger async close issue. > > The main changes compared to the first webrew are as follows: > > - the POLL-constants related stuff has been factored out into its own > webrev ("8031997: PPC64: Make the various POLL constants system > dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). I see this has been pushed to ppc-aix-port/stage-9. Would you have any objection if I brought this into jdk9/dev (minus the AixPollPort change)? We can use a different bug number so as not to cause duplicate bug issues. It should trivially merge when you come to sync'ing up the staging forest. > - the "Async close on AIX" workarounds have been taken out as well > and will be handled separately Thanks for separating this one out as I suspect this that doing this cleanly is going to involve changes for all platforms. -Alan. From volker.simonis at gmail.com Mon Jan 20 08:29:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 17:29:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD3F91.7020202@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > On 20/01/2014 13:45, Volker Simonis wrote: >> >> : >> Hi everybody, >> >> so here's the second version of this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ > > This looks okay to me. Thanks. > > The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can > be fixed before you push this (no need to generate a few webrev of course). > Sorry, I've just fixed it in my patch queue and will used the fixed version for pushing. @Vladimir: could you please run this change (http://cr.openjdk.java.net/~simonis/webrevs/8031581_2) through JPRT as well. I'll push it (together with the fixed typo in the comment) if everything is OK. > For the JDWP socket transport then it's interesting that shutdown is being > used to cause the reader thread to be preempted. That may be useful when it > comes to addressing the bigger async close issue. > > >> >> The main changes compared to the first webrew are as follows: >> >> - the POLL-constants related stuff has been factored out into its own >> webrev ("8031997: PPC64: Make the various POLL constants system >> dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). > > I see this has been pushed to ppc-aix-port/stage-9. Would you have any > objection if I brought this into jdk9/dev (minus the AixPollPort change)? We > can use a different bug number so as not to cause duplicate bug issues. It > should trivially merge when you come to sync'ing up the staging forest. > I have no objections of course. I'm just not sure what exact implications this will have. @Vladimir: what do you think - can Alan push "8031997: PPC64: Make the various POLL constants system dependant" minus the Aix-specific stuff to jdk9/dev now, without causing you any harm during integration. @Alan: on the other hand, the bulk integration from ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so maybe you could wait until that happens? Thanks, Volker > >> - the "Async close on AIX" workarounds have been taken out as well >> and will be handled separately > > Thanks for separating this one out as I suspect this that doing this cleanly > is going to involve changes for all platforms. > > -Alan. From Alan.Bateman at oracle.com Mon Jan 20 08:42:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 16:42:39 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: <52DD51FF.7060502@oracle.com> On 20/01/2014 16:29, Volker Simonis wrote: > : > > @Alan: on the other hand, the bulk integration from > ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so > maybe you could wait until that happens? > In that case then ignore my request, I assumed it would not be pushed to jdk9/dev until end-Feb. -Alan From volker.simonis at gmail.com Mon Jan 20 11:57:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 20:57:03 +0100 Subject: 7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X In-Reply-To: <52DD10A1.3040202@oracle.com> References: <52DD10A1.3040202@oracle.com> Message-ID: Hi Alan, I've tried your patch with our port on AIX. The good news is that it fixes: java/nio/channels/AsynchronousFileChannel/Lock.java on AIX as well. The bad news is, that it doesn't seem to help for: java/nio/channels/AsyncCloseAndInterrupt.java Here's a stack trace of where the VM gets stuck: TestThread-FileChannel/transferTo/interrupt" #12 daemon prio=5 os_prio=57 tid=0x0000000119c07800 nid=0x1310131 runnable [0x000000011 a1e3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:51) at sun.nio.ch.SinkChannelImpl.write(SinkChannelImpl.java:167) - locked <0x0a000100255c9330> (a java.lang.Object) at sun.nio.ch.FileChannelImpl.transferToTrustedChannel(FileChannelImpl.java:468) at sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:564) at AsyncCloseAndInterrupt$18.doIO(AsyncCloseAndInterrupt.java:391) at AsyncCloseAndInterrupt$Tester.go(AsyncCloseAndInterrupt.java:485) at TestThread.run(TestThread.java:55) "MainThread" #9 prio=5 os_prio=57 tid=0x0000000119289800 nid=0x2d50115 runnable [0x0000000119497000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.FileDispatcherImpl.preClose0(Native Method) at sun.nio.ch.FileDispatcherImpl.preClose(FileDispatcherImpl.java:102) at sun.nio.ch.SinkChannelImpl.implCloseSelectableChannel(SinkChannelImpl.java:88) - locked <0x0a000100255c9340> (a java.lang.Object) at java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:234) at java.nio.channels.spi.AbstractInterruptibleChannel$1.interrupt(AbstractInterruptibleChannel.java:165) - locked <0x0a000100255c9300> (a java.lang.Object) at java.lang.Thread.interrupt(Thread.java:918) - locked <0x0a000100255ceca0> (a java.lang.Object) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:573) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:609) at AsyncCloseAndInterrupt.main(AsyncCloseAndInterrupt.java:680) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) As you can see, it hangs in preclose, because it is also blocked in write. I think here is where calling the interruptible write in my initial change helped. But now, after I saw your solution here for 7133499 I wonder if the same technique you applied in FileChannelImpl.implCloseChannel() wouldn't work here as well. However if I naively call NativeThread.signal(th) before calling nd.preClose(fd) in SinkChannelImpl.implCloseSelectableChannel() this improves the situation only slightly, because the VM now hangs in a read(): "TestThread-FileChannel/transferFrom/interrupt" #12 daemon prio=5 os_prio=57 tid=0x00000001199a0800 nid=0x429000f runnable [0x0000000119f02000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.FileDispatcherImpl.read(FileDispatcherImpl.java:46) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:192) at sun.nio.ch.SourceChannelImpl.read(SourceChannelImpl.java:167) - locked <0x0a0001003ab1ee68> (a java.lang.Object) at sun.nio.ch.FileChannelImpl.transferFromArbitraryChannel(FileChannelImpl.java:625) at sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:663) at AsyncCloseAndInterrupt$19.doIO(AsyncCloseAndInterrupt.java:401) at AsyncCloseAndInterrupt$Tester.go(AsyncCloseAndInterrupt.java:485) at TestThread.run(TestThread.java:55) "main" #1 prio=5 os_prio=57 tid=0x000000011022c800 nid=0x50e0101 runnable [0x000000011021d000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.FileDispatcherImpl.preClose0(Native Method) at sun.nio.ch.FileDispatcherImpl.preClose(FileDispatcherImpl.java:102) at sun.nio.ch.SourceChannelImpl.implCloseSelectableChannel(SourceChannelImpl.java:88) - locked <0x0a0001003ab1ee78> (a java.lang.Object) at java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:234) at java.nio.channels.spi.AbstractInterruptibleChannel$1.interrupt(AbstractInterruptibleChannel.java:165) - locked <0x0a0001003ab1ee38> (a java.lang.Object) at java.lang.Thread.interrupt(Thread.java:918) - locked <0x0a0001003ab1f5b8> (a java.lang.Object) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:573) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:609) at AsyncCloseAndInterrupt.main(AsyncCloseAndInterrupt.java:681) So I wonder if we would have to wrap all Java-calls to close()/preClose() with NativeThread.signal() and all calls to IO-functions like read/write/fcntl with NativeThreadSet.add()/remove()? Maybe then its easier doing it in the native interface (i.e. the NET_ wrappers) to just mimic the "usual" behaviour on AIX? Regards, Volker On Mon, Jan 20, 2014 at 1:03 PM, Alan Bateman wrote: > > One of the outstanding issues from the OS X port is that the async close of > a FileChannel where there are threads blocked doing I/O operation does not > work, instead close hang (potentially indefinitely, say when another thread > is blocked waiting for a file lock to be acquired or where the file is > something like a pipe or other type of file where you can block > indefinitely). From what I can tell, it wasn't implemented in Apple's JDK6 > either. > > In order to fix this on OS X then close needs to signal all threads that are > blocked in I/O operations, something we already do on Linux. The other part > is removing the preClose (the dup2) from the closing of FileChannels as it > is not needed when you can signal. The webrev with the proposed changes is > here: > > http://cr.openjdk.java.net/~alanb/7133499/webrev/ > > Fixing this issue means that two tests can be removed from the exclude list > (there is third test removed from the exclude list too, that shouldn't have > been there). > > -Alan. From Alan.Bateman at oracle.com Mon Jan 20 13:34:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 21:34:18 +0000 Subject: 7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X In-Reply-To: References: <52DD10A1.3040202@oracle.com> Message-ID: <52DD965A.1030505@oracle.com> On 20/01/2014 19:57, Volker Simonis wrote: > Hi Alan, > > I've tried your patch with our port on AIX. > The good news is that it fixes: > > java/nio/channels/AsynchronousFileChannel/Lock.java > > on AIX as well. > > The bad news is, that it doesn't seem to help for: > > java/nio/channels/AsyncCloseAndInterrupt.java > > Here's a stack trace of where the VM gets stuck: In these stack traces then the channels are Pipe.SourceChannel or Pipe.SinkChannel where the file descriptor is to one end of a pipe. Are these the only cases where you see these hangs? I'm interested to know if the async close of SocketChannel and ServerSocketChannel when configured blocked also hangs (I will guess that it will as the behavior is likely to be the same as pipe). I have an idea on how to fix this so that the preClose isn't used when the channel is configured blocking (or isn't registered with a Selector). The patch doesn't use NativeThreadSet because it isn't efficient when the number of threads is limited to 1 or 2 (FileChannel uses NativeThreadSet because it defines positional read/write and so the number of concurrent reader/writers is unlimited). I'll send a patch the other channels soon and we can see if this works for you. If it does work then I have a bit of a preference to being it in via jdk9/dev rather than via the AIX staging forest because the changes impact all platforms. That said, if we being this FileChannel fix for OSX in then it means that the platform specific changes would be in, the patch for the other platforms shouldn't require porting. -Alan. From david.holmes at oracle.com Mon Jan 20 18:49:01 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 12:49:01 +1000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> <52DC8DA9.2010106@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap> Message-ID: <52DDE01D.1060605@oracle.com> On 20/01/2014 11:41 PM, Lindenmaier, Goetz wrote: > Hi David, > > I understand your arguments and basically agree with them. > If the serialization page does not work on PPC, your solution > 1) is best. > > But I'm not sure why there should be a link between TSO and whether > the serialization page trick works. Second depends, as you say, > on the OS implementation. My limited understanding is that on RMO-based systems the requirements for: "Synchronization based on page-protections - mprotect()" as described in: http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt may not always hold. Dave Dice would need to provide more details if needed. Cheers, David > I would assume that the write to the serialization page causes > the OS to generate a new TLB entry or the like, involving the > use of a ptwsync instruction which would be fine. But we are > investigating this. > > We are also experimenting with a small regression test to find > out whether the serialization page ever fails. > > Best regards, > Goetz. > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 20. Januar 2014 03:45 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' > Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization > > On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I had a look at the first part of this issue: Whether StoreStore >> is necessary in the interpreter. Let's for now assume the serialization >> page mechanism works on PPC. >> >> In the state transition leaving the VM state, which is executed in the >> destructor, ThreadStateTransition::transition() is called, which executes >> if (UseMembar) { >> OrderAccess::fence(); >> } else { >> os::write_memory_serialize_page(thread); >> } >> >> os:: write_memory_serialize_page() can not be considered a proper >> MemBar, as it only serializes if another thread poisoned the page. >> Thus it does not qualify to order the initialization and the publishing >> of the object. >> >> You are right, if UseMembar is true, the StoreStore in the interpreter >> is superfluous. We could guard the StoreStores in the interpreter by >> !UseMembar. > > My understanding, from our existing non-TSO system ports, is that the > present assumption is that either: > > a) you have a TSO system, in which case you are probably using the > serialization page, but you don't need any barrier to enforce ordering > anyway; or > > b) you don't have a TSO system, you are using UseMembar==true and so you > get a full fence inserted that enforces the ordering anyway. > > So the ordering requirements are satisfied by piggy-backing on the > UseMembar setting that comes from the thread state transition code, > which forms part of the "runtime entry" code. That's not to say that you > will necessarily find this applied consistently in all places where it > might be applied - nor will you necessarily find that this is common > knowledge amongst VM engineers. > > Technically the storeStore barriers could be conditional on !UseMembar > but that is redundant in the current usage. > >> But then again, one is to order the publishing of the thread states, >> the other to enforce some Java semantics. I don't know whether everybody >> who changes in one place is aware of both issues. But if you want to, >> I'll add a !UseMembar in the interpreter. > > Here are my preferred options in order: > > 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - > rely on the piggy-backing effect. > > 2. Conditionalize the new storeStore barriers on !UseMembar. This > unfortunately penalizes all platforms with a runtime check. > > 3. Add the storeStores unconditionally. This penalizes platforms that > set UseMembar==true as we will now get two fences at runtime. > > I know we're talking about the interpreter here so performance is not > exactly critical, but still ... > >> Maybe it would be a good idea >> to document the double use in interfaceSupport.cpp, too. And maybe >> add an assertion of some kind. > > interfaceSupport doesn't know that other code piggy-backs on the fact > state-transitions have full fences when UseMembar is true. If it is > documented anywhere it should be in the interpreter (and any other > places that makes the same assumption) - something like: > > // On non-TSO systems there can be additional ordering constraints > // between Java-level actions (such as allocation and constructor > // invocation) that in principle need explicit memory barriers. > // However, on many non-TSO systems the thread-state transition logic > // in the IRT_ENTRY code will insert a full fence due to the use of > // UseMembar==true, which provides the necessary ordering guarantees. > >> >> We're digging into the other issue currenty, whether the serialization page >> works on ppc. We understand your concerns and have no simple answer to >> it right now. At least, in our VM and in the port there are no known problems >> with the state transitions. > > Even if the memory serialization page does not work, in a guaranteed > sense, on PPC-AIX, it is extremely unlikely that testing would expose > this. Also note that the memory serialization page behaviour is more a > function of the OS - so it may be that AIX is different to linux in that > regard. > > Cheers, > David > ----- > >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Donnerstag, 16. Januar 2014 19:16 >> To: David Holmes; Lindenmaier, Goetz >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' >> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization >> >> Changes are in C++ Interpreter so it does not affect Oracle VM. >> But David has point here. I would like to hear the explanation too. >> >> BTW, I see that for ppc64: >> >> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); >> >> as result write_memory_serialize_page() is used in >> ThreadStateTransition::transition(). >> >> Is it not enough on PPC64? >> >> Thanks, >> Vladimir >> >> On 1/15/14 9:30 PM, David Holmes wrote: >>> Can I get some response on this please - specifically the redundancy wrt >>> IRT_ENTRY actions. >>> >>> Thanks, >>> David >>> >>> On 20/12/2013 11:55 AM, David Holmes wrote: >>>> Still catching up ... >>>> >>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> this change adds StoreStore barriers after object initialization and >>>>> after constructor calls in the C++ interpreter. This assures no >>>>> uninitialized >>>>> objects or final fields are visible. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >>>> >>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >>>> thread state transitions that already include a full "fence" so the >>>> storestore barriers are redundant in those cases. >>>> >>>> The fastpath _new storestore seems okay. >>>> >>>> I don't know how handle_return gets used to know if it is reasonable or >>>> not. >>>> >>>> I was trying, unsuccessfully, to examine the same code in the >>>> templateInterpreter to see how it handles these cases as it naturally >>>> has the same object-initialization-safety requirements (though these can >>>> be handled in a number of different ways other than an unconditional >>>> storestore barrier at the end of the initialization and construction >>>> phases. >>>> >>>> David >>>> ----- >>>> >>>>> Please review and test this change. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From david.holmes at oracle.com Mon Jan 20 20:54:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 14:54:53 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> Message-ID: <52DDFD9D.3050205@oracle.com> Hi Goetz, On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: > Hi, > > I tried to come up with a webrev that implements the change as proposed in > your mails: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > > Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use > support_IRIW_for_not_multiple_copy_atomic_cpu. Given the flag name the commentary eg: + // Support ordering of "Independent Reads of Independent Writes". + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { seems somewhat redundant. > I left the definition and handling of _wrote_volatile in the code, without > any protection. + bool _wrote_volatile; // Did we write a final field? s/final/volatile > I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , > and put it on one line. > > I removed the comment in library_call.cpp. > I also removed the sentence " Solution: implement volatile read as sync-load-acquire." > from the comments as it's PPC specific. I think the primary IRIW comment/explanation should go in globalDefinitions.hpp where support_IRIW_for_not_multiple_copy_atomic_cpu is defined. > Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these > issues in C1 if nobody did it by then. I've filed: https://bugs.openjdk.java.net/browse/JDK-8032366 "Implement C1 support for IRIW conformance on non-multiple-copy-atomic platforms" to cover this task, as it may be needed sooner rather than later. > Wrt. to performance: Oracle will soon do heavy testing of the port. If any > performance problems arise, we still can add #ifdef PPC64 to circumvent this. Ok. Thanks, David > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 16. Januar 2014 10:05 > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >> On 1/16/14 12:34 AM, David Holmes wrote: >>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>> want to keep it this way, it could be useful to have such info on other >>>> platforms too. But I would suggest to remove PPC64 comments in >>>> parse.hpp. >>>> >>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>> which could be checked in all places instead of #ifdef: >>> >>> I asked for the ifdef some time back as I find it much preferable to >>> have this as a build-time construct rather than a >>> runtime one. I don't want to have to pay anything for this if we don't >>> use it. >> >> Any decent C++ compiler will optimize expressions with such constants >> defined in header files. I insist to avoid #ifdefs in C2 code. I really >> don't like the code with #ifdef in unsafe.cpp but I can live with it. > > If you insist then we may as well do it all the same way. Better to be > consistent. > > My apologies Goetz for wasting your time going back and forth on this. > > That aside I have a further concern with this IRIW support - it is > incomplete as there is no C1 support, as PPC64 isn't using client. If > this is going on then we (which probably means the Oracle 'we') need to > add the missing C1 code. > > David > ----- > >> Vladimir >> >>> >>> David >>> >>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>> #else >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>> #endif >>>> >>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>> >>>> and then: >>>> >>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>> oop p = JNIHandles::resolve(obj); \ >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>> OrderAccess::fence(); \ >>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>> >>>> And: >>>> >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>> field->is_volatile()) { >>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>> + } >>>> >>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>> >>>> The code in parse1.cpp could be put on one line: >>>> >>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>> method()->is_initializer()) )) { >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> I updated the webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> >>>>>> - I removed the IRIW example in parse3.cpp >>>>>> - I adapted the comments not to point to that comment, and to >>>>>> reflect the new flagging. Also I mention that we support the >>>>>> volatile constructor issue, but that it's not standard. >>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>> I also think it's better to separate these this way. >>>>> >>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>> please. >>>>> >>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>> comment doesn't make much sense to me and refers to >>>>> ppc specific stuff in a shared file: >>>>> >>>>> if (is_volatile) { >>>>> ! if (!is_store) { >>>>> insert_mem_bar(Op_MemBarAcquire); >>>>> ! } else { >>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>> insert_mem_bar(Op_MemBarVolatile); >>>>> + #endif >>>>> + } >>>>> >>>>> I don't think the comment is needed. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks for your comments! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Sorry for the delay in getting back to this. >>>>>> >>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>> specifically it is >>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>> the commentary excessive, particularly for shared code. In particular >>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>> explanation and I don't think we need it to that level of detail. >>>>>> Seems >>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>> >>>>>> The changes related to volatile writes in the constructor, as >>>>>> discussed >>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>> PPC64 porters. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>> this version. >>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lindenmaier, Goetz >>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>> To: David Holmes >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>> not >>>>>>>> required to pass. >>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>> worked >>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>> it by >>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>> part is >>>>>>> not that performance relevant. >>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>> I added a compile-time guard in this new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>> several double negations I don't like, (#ifNdef >>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>> but this way I only have to change the ppc platform. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>> emails. >>>>>>> >>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>> settled. >>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>> >>>>>>>> About our change: David, the causality is the other way round. >>>>>>>> The change is about IRIW. >>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>> >>>>>>> This is the part I still have some question marks over as the >>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>> But I'm >>>>>>> no further along in processing that paper I'm afraid. >>>>>>> >>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>> stores. >>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>> constructor tests. >>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>> after stores >>>>>>>> to pass the volatile constructor tests. >>>>>>> >>>>>>> So we can at least undo #4 now we have established those tests >>>>>>> were not >>>>>>> required to pass. >>>>>>> >>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>> order >>>>>>>> instructions are not as find-granular as the >>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>> The only instruction >>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>> therefore the >>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>> proper representation >>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>> it's pointless >>>>>>>> anyways. >>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>> I'd be happy to add a property >>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>> >>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>> think >>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>> based not architecture based) as that will allows for turning this >>>>>>> on/off for any architecture for testing purposes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>> Or also >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> TL;DR version: >>>>>>>> >>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>> constructor-barrier >>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>> *may* >>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>> ensure >>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>> invalid >>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>> need it >>>>>>>> due to other factors). >>>>>>>> >>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>> term :) >>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>> >>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>> visible to >>>>>>>> all other hardware threads at the same time point; these >>>>>>>> architectures >>>>>>>> are not multiple-copy atomic." >>>>>>>> >>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>> ARM and >>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>> current issue is what you wrote below: >>>>>>>> >>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>> > remove the sync instruction from behind stores >>>>>>>> (parse3.cpp:320) >>>>>>>> > and place it before loads. >>>>>>>> >>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>> after >>>>>>>> the store then you have to do something around the loads to get the >>>>>>>> same >>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>> load - >>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>> clearer. >>>>>>>> >>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>> volatile_store were factored out so that they could be >>>>>>>> implemented as >>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>> hooks >>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>> >>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>> this >>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>> >>>>>>>>> I did not yet add the >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> or >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>> >>>>>>>>> >>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>> >>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>> >>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>> store >>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>> (volatile store in constructor). >>>>>>>>> >>>>>>>>> >>>>>>>>> @David >>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>> issue. >>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>> you >>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>> solution, >>>>>>>>> we would volunteer to implement and test it. >>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> @David >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>> and >>>>>>>>>> can't find any reference to it. >>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>> ARM and >>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>> Work-Stealing for >>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>> taskqueue problem. >>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>> >>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>> used 'read' >>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>> above). >>>>>>>>> >>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>> processors >>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>> Aleksey!) >>>>>>>>> >>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>> >>>>>>>>>> -- IRIW issue >>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>> a few >>>>>>>>>>> moments thought. >>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>> problem yet, >>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>> >>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>> continuous. >>>>>>>>> >>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) >>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>> I contributed a >>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>> nice, I admit. >>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>> are evaluated >>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>> >>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>> problem >>>>>>>>>> is that >>>>>>>>>> store >>>>>>>>>> sync >>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>> only >>>>>>>>>> sync >>>>>>>>>> load >>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>> pass that test. >>>>>>>>> >>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>> term and >>>>>>>>> can't find any reference to it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> The JMM is fine. And >>>>>>>>>> store >>>>>>>>>> MemBarVolatile >>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>> that >>>>>>>>>> do what is required. >>>>>>>>>> >>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>> >>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>> initializing >>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>> Shipilev >>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>> LongVolatileTest >>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>> will fail. >>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>> volatile field would be >>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>> AtomicInteger.) >>>>>>>>>> >>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>> volatiles do >>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>> that >>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>> Aleksey >>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>> missing constructor barrier. >>>>>>>>>> >>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>> heavyweight >>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>> don't >>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>> >>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>> OrderAccess operations >>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>> account >>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>> different platforms >>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>> An example: >>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>> this: >>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>> Just doing what is required. >>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>> fine grained operations: >>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>> are more (too) powerful, >>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>> can not implement >>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>> >>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>> issue. >>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>> read >>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>> >>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>> independent? >>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>> >>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>> few >>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>> will >>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>> moment. The >>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>> requirements for >>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>> are not >>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>> store >>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>> of the >>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>> software >>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>> don't have >>>>>>>>>> that on ppc!) >>>>>>>>>> >>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>> I will >>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -- Other ports: >>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>> it might >>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>> them). >>>>>>>>>>> >>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>> can >>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>> way :) >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>> >>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>> fix an >>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>> IRIW >>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>> doing the >>>>>>>>>>> load. >>>>>>>>>>> >>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>> would be >>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>> performance >>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>> that >>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>> this is >>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>> with the >>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>> the >>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>> properties >>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>> on a >>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>> reduce >>>>>>>>>>> to a no-op. >>>>>>>>>>> >>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>> under >>>>>>>>>>> the JMM. >>>>>>>>>>> >>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>> current >>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>> is set >>>>>>>>>>>> depending on platform: >>>>>>>>>>>> >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>> >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>> Java >>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>> explicitly >>>>>>>>>>> like this. >>>>>>>>>>> >>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>> there >>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>> defines? >>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>> David? >>>>>>>>>>> >>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>> inside else {}. >>>>>>>>>>>> >>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>> specific which >>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>> #ifdefs. >>>>>>>>>>>> >>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>> >>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>> #else >>>>>>>>>>>> if (is_field) { >>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>> volatile field >>>>>>>>>>>> (PPC64). >>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>> } >>>>>>>>>>>> #endif >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> Example: >>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>> >>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>> >>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>> is only >>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>> threads >>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>> >>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>> >>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>> fields >>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>> published. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>> seems too >>>>>>>>>>>>> strong. >>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>> suffice. >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> From goetz.lindenmaier at sap.com Tue Jan 21 01:22:08 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Jan 2014 09:22:08 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52DDFD9D.3050205@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> Hi, I made a new webrev http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ differing from http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ only in the comments. I removed // Support ordering of "Independent Reads of Independent Writes". everywhere, and edited the comments in the globalDefinition*.hpp files. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 21. Januar 2014 05:55 To: Lindenmaier, Goetz; Vladimir Kozlov Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi Goetz, On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: > Hi, > > I tried to come up with a webrev that implements the change as proposed in > your mails: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > > Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use > support_IRIW_for_not_multiple_copy_atomic_cpu. Given the flag name the commentary eg: + // Support ordering of "Independent Reads of Independent Writes". + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { seems somewhat redundant. > I left the definition and handling of _wrote_volatile in the code, without > any protection. + bool _wrote_volatile; // Did we write a final field? s/final/volatile > I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , > and put it on one line. > > I removed the comment in library_call.cpp. > I also removed the sentence " Solution: implement volatile read as sync-load-acquire." > from the comments as it's PPC specific. I think the primary IRIW comment/explanation should go in globalDefinitions.hpp where support_IRIW_for_not_multiple_copy_atomic_cpu is defined. > Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these > issues in C1 if nobody did it by then. I've filed: https://bugs.openjdk.java.net/browse/JDK-8032366 "Implement C1 support for IRIW conformance on non-multiple-copy-atomic platforms" to cover this task, as it may be needed sooner rather than later. > Wrt. to performance: Oracle will soon do heavy testing of the port. If any > performance problems arise, we still can add #ifdef PPC64 to circumvent this. Ok. Thanks, David > Best regards, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 16. Januar 2014 10:05 > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >> On 1/16/14 12:34 AM, David Holmes wrote: >>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>> want to keep it this way, it could be useful to have such info on other >>>> platforms too. But I would suggest to remove PPC64 comments in >>>> parse.hpp. >>>> >>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>> which could be checked in all places instead of #ifdef: >>> >>> I asked for the ifdef some time back as I find it much preferable to >>> have this as a build-time construct rather than a >>> runtime one. I don't want to have to pay anything for this if we don't >>> use it. >> >> Any decent C++ compiler will optimize expressions with such constants >> defined in header files. I insist to avoid #ifdefs in C2 code. I really >> don't like the code with #ifdef in unsafe.cpp but I can live with it. > > If you insist then we may as well do it all the same way. Better to be > consistent. > > My apologies Goetz for wasting your time going back and forth on this. > > That aside I have a further concern with this IRIW support - it is > incomplete as there is no C1 support, as PPC64 isn't using client. If > this is going on then we (which probably means the Oracle 'we') need to > add the missing C1 code. > > David > ----- > >> Vladimir >> >>> >>> David >>> >>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>> #else >>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>> #endif >>>> >>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>> >>>> and then: >>>> >>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>> oop p = JNIHandles::resolve(obj); \ >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>> OrderAccess::fence(); \ >>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>> >>>> And: >>>> >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>> field->is_volatile()) { >>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>> + } >>>> >>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>> >>>> The code in parse1.cpp could be put on one line: >>>> >>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>> method()->is_initializer()) )) { >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> I updated the webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>> >>>>>> - I removed the IRIW example in parse3.cpp >>>>>> - I adapted the comments not to point to that comment, and to >>>>>> reflect the new flagging. Also I mention that we support the >>>>>> volatile constructor issue, but that it's not standard. >>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>> I also think it's better to separate these this way. >>>>> >>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>> please. >>>>> >>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>> comment doesn't make much sense to me and refers to >>>>> ppc specific stuff in a shared file: >>>>> >>>>> if (is_volatile) { >>>>> ! if (!is_store) { >>>>> insert_mem_bar(Op_MemBarAcquire); >>>>> ! } else { >>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>> insert_mem_bar(Op_MemBarVolatile); >>>>> + #endif >>>>> + } >>>>> >>>>> I don't think the comment is needed. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks for your comments! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Sorry for the delay in getting back to this. >>>>>> >>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>> specifically it is >>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>> the commentary excessive, particularly for shared code. In particular >>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>> explanation and I don't think we need it to that level of detail. >>>>>> Seems >>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>> >>>>>> The changes related to volatile writes in the constructor, as >>>>>> discussed >>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>> PPC64 porters. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>> this version. >>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lindenmaier, Goetz >>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>> To: David Holmes >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>> not >>>>>>>> required to pass. >>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>> worked >>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>> it by >>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>> part is >>>>>>> not that performance relevant. >>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>> I added a compile-time guard in this new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>> several double negations I don't like, (#ifNdef >>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>> but this way I only have to change the ppc platform. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>> emails. >>>>>>> >>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>> settled. >>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>> >>>>>>>> About our change: David, the causality is the other way round. >>>>>>>> The change is about IRIW. >>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>> >>>>>>> This is the part I still have some question marks over as the >>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>> But I'm >>>>>>> no further along in processing that paper I'm afraid. >>>>>>> >>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>> stores. >>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>> constructor tests. >>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>> after stores >>>>>>>> to pass the volatile constructor tests. >>>>>>> >>>>>>> So we can at least undo #4 now we have established those tests >>>>>>> were not >>>>>>> required to pass. >>>>>>> >>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>> order >>>>>>>> instructions are not as find-granular as the >>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>> The only instruction >>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>> therefore the >>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>> proper representation >>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>> it's pointless >>>>>>>> anyways. >>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>> I'd be happy to add a property >>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>> >>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>> think >>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>> based not architecture based) as that will allows for turning this >>>>>>> on/off for any architecture for testing purposes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>> Or also >>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> TL;DR version: >>>>>>>> >>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>> constructor-barrier >>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>> *may* >>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>> ensure >>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>> invalid >>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>> need it >>>>>>>> due to other factors). >>>>>>>> >>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>> term :) >>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>> >>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>> visible to >>>>>>>> all other hardware threads at the same time point; these >>>>>>>> architectures >>>>>>>> are not multiple-copy atomic." >>>>>>>> >>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>> ARM and >>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>> current issue is what you wrote below: >>>>>>>> >>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>> > remove the sync instruction from behind stores >>>>>>>> (parse3.cpp:320) >>>>>>>> > and place it before loads. >>>>>>>> >>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>> after >>>>>>>> the store then you have to do something around the loads to get the >>>>>>>> same >>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>> load - >>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>> clearer. >>>>>>>> >>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>> volatile_store were factored out so that they could be >>>>>>>> implemented as >>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>> hooks >>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>> >>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>> this >>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>> >>>>>>>>> I did not yet add the >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> or >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>> >>>>>>>>> >>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>> >>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>> >>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>> store >>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>> (volatile store in constructor). >>>>>>>>> >>>>>>>>> >>>>>>>>> @David >>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>> issue. >>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>> you >>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>> solution, >>>>>>>>> we would volunteer to implement and test it. >>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> @David >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>> and >>>>>>>>>> can't find any reference to it. >>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>> ARM and >>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>> Work-Stealing for >>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>> taskqueue problem. >>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>> >>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>> used 'read' >>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>> above). >>>>>>>>> >>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>> processors >>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>> Aleksey!) >>>>>>>>> >>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>> >>>>>>>>>> -- IRIW issue >>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>> a few >>>>>>>>>>> moments thought. >>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>> problem yet, >>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>> >>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>> continuous. >>>>>>>>> >>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) >>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>> I contributed a >>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>> nice, I admit. >>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>> are evaluated >>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>> >>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>> problem >>>>>>>>>> is that >>>>>>>>>> store >>>>>>>>>> sync >>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>> only >>>>>>>>>> sync >>>>>>>>>> load >>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>> pass that test. >>>>>>>>> >>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>> term and >>>>>>>>> can't find any reference to it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> The JMM is fine. And >>>>>>>>>> store >>>>>>>>>> MemBarVolatile >>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>> that >>>>>>>>>> do what is required. >>>>>>>>>> >>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>> >>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>> initializing >>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>> Shipilev >>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>> LongVolatileTest >>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>> will fail. >>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>> volatile field would be >>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>> AtomicInteger.) >>>>>>>>>> >>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>> volatiles do >>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>> that >>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>> Aleksey >>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>> missing constructor barrier. >>>>>>>>>> >>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>> heavyweight >>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>> don't >>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>> >>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>> OrderAccess operations >>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>> account >>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>> different platforms >>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>> An example: >>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>> this: >>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>> Just doing what is required. >>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>> fine grained operations: >>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>> are more (too) powerful, >>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>> can not implement >>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>> >>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>> issue. >>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>> read >>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>> >>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>> independent? >>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>> >>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>> few >>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>> will >>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>> moment. The >>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>> requirements for >>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>> are not >>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>> store >>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>> of the >>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>> software >>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>> don't have >>>>>>>>>> that on ppc!) >>>>>>>>>> >>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>> I will >>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -- Other ports: >>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>> it might >>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>> them). >>>>>>>>>>> >>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>> can >>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>> way :) >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>> >>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>> fix an >>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>> IRIW >>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>> doing the >>>>>>>>>>> load. >>>>>>>>>>> >>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>> would be >>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>> performance >>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>> that >>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>> this is >>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>> with the >>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>> the >>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>> properties >>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>> on a >>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>> reduce >>>>>>>>>>> to a no-op. >>>>>>>>>>> >>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>> under >>>>>>>>>>> the JMM. >>>>>>>>>>> >>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>> current >>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>> is set >>>>>>>>>>>> depending on platform: >>>>>>>>>>>> >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>> >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>> Java >>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>> explicitly >>>>>>>>>>> like this. >>>>>>>>>>> >>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>> there >>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>> defines? >>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>> David? >>>>>>>>>>> >>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>> inside else {}. >>>>>>>>>>>> >>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>> specific which >>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>> #ifdefs. >>>>>>>>>>>> >>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>> >>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>> #else >>>>>>>>>>>> if (is_field) { >>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>> volatile field >>>>>>>>>>>> (PPC64). >>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>> } >>>>>>>>>>>> #endif >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> Example: >>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>> >>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>> >>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>> is only >>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>> threads >>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>> >>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>> >>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>> fields >>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>> published. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>> seems too >>>>>>>>>>>>> strong. >>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>> suffice. >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> From david.holmes at oracle.com Tue Jan 21 03:53:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 21:53:20 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> Message-ID: <52DE5FB0.5000808@oracle.com> Thanks Goetz! This typo still exists: + bool _wrote_volatile; // Did we write a final field? s/final/volatile/ Otherwise no further comments from me. David On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: > Hi, > > I made a new webrev > http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ > differing from > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > only in the comments. > > I removed > // Support ordering of "Independent Reads of Independent Writes". > everywhere, and edited the comments in the globalDefinition*.hpp > files. > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 21. Januar 2014 05:55 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I tried to come up with a webrev that implements the change as proposed in >> your mails: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >> >> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >> support_IRIW_for_not_multiple_copy_atomic_cpu. > > Given the flag name the commentary eg: > > + // Support ordering of "Independent Reads of Independent Writes". > + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { > > seems somewhat redundant. > >> I left the definition and handling of _wrote_volatile in the code, without >> any protection. > > + bool _wrote_volatile; // Did we write a final field? > > s/final/volatile > >> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >> and put it on one line. >> >> I removed the comment in library_call.cpp. >> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >> from the comments as it's PPC specific. > > I think the primary IRIW comment/explanation should go in > globalDefinitions.hpp where > support_IRIW_for_not_multiple_copy_atomic_cpu is defined. > >> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >> issues in C1 if nobody did it by then. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8032366 > > "Implement C1 support for IRIW conformance on non-multiple-copy-atomic > platforms" > > to cover this task, as it may be needed sooner rather than later. > >> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >> performance problems arise, we still can add #ifdef PPC64 to circumvent this. > > Ok. > > Thanks, > David > >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 16. Januar 2014 10:05 >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>> On 1/16/14 12:34 AM, David Holmes wrote: >>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>> want to keep it this way, it could be useful to have such info on other >>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>> parse.hpp. >>>>> >>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>> which could be checked in all places instead of #ifdef: >>>> >>>> I asked for the ifdef some time back as I find it much preferable to >>>> have this as a build-time construct rather than a >>>> runtime one. I don't want to have to pay anything for this if we don't >>>> use it. >>> >>> Any decent C++ compiler will optimize expressions with such constants >>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >> >> If you insist then we may as well do it all the same way. Better to be >> consistent. >> >> My apologies Goetz for wasting your time going back and forth on this. >> >> That aside I have a further concern with this IRIW support - it is >> incomplete as there is no C1 support, as PPC64 isn't using client. If >> this is going on then we (which probably means the Oracle 'we') need to >> add the missing C1 code. >> >> David >> ----- >> >>> Vladimir >>> >>>> >>>> David >>>> >>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>> #else >>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>> #endif >>>>> >>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>> >>>>> and then: >>>>> >>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>> oop p = JNIHandles::resolve(obj); \ >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>> OrderAccess::fence(); \ >>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>> >>>>> And: >>>>> >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>> field->is_volatile()) { >>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>> + } >>>>> >>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>> >>>>> The code in parse1.cpp could be put on one line: >>>>> >>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>> method()->is_initializer()) )) { >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I updated the webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>> volatile constructor issue, but that it's not standard. >>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>> I also think it's better to separate these this way. >>>>>> >>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>> please. >>>>>> >>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>> comment doesn't make much sense to me and refers to >>>>>> ppc specific stuff in a shared file: >>>>>> >>>>>> if (is_volatile) { >>>>>> ! if (!is_store) { >>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>> ! } else { >>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>> + #endif >>>>>> + } >>>>>> >>>>>> I don't think the comment is needed. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks for your comments! >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> Sorry for the delay in getting back to this. >>>>>>> >>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>> specifically it is >>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>> Seems >>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>> >>>>>>> The changes related to volatile writes in the constructor, as >>>>>>> discussed >>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>> PPC64 porters. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>> this version. >>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lindenmaier, Goetz >>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>> To: David Holmes >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>> not >>>>>>>>> required to pass. >>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>> worked >>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>> it by >>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>> part is >>>>>>>> not that performance relevant. >>>>>>>> >>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>> think >>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>> but this way I only have to change the ppc platform. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz >>>>>>>> >>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>> emails. >>>>>>>> >>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>> settled. >>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>> >>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>> The change is about IRIW. >>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>> >>>>>>>> This is the part I still have some question marks over as the >>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>> But I'm >>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>> >>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>> stores. >>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>> constructor tests. >>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>> after stores >>>>>>>>> to pass the volatile constructor tests. >>>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>> were not >>>>>>>> required to pass. >>>>>>>> >>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>> order >>>>>>>>> instructions are not as find-granular as the >>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>> The only instruction >>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>> therefore the >>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>> proper representation >>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>> it's pointless >>>>>>>>> anyways. >>>>>>>>> >>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>> I'd be happy to add a property >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>> on/off for any architecture for testing purposes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>> Or also >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> TL;DR version: >>>>>>>>> >>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>> constructor-barrier >>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>> *may* >>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>> ensure >>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>> invalid >>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>> need it >>>>>>>>> due to other factors). >>>>>>>>> >>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>> term :) >>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>> >>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>> visible to >>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>> architectures >>>>>>>>> are not multiple-copy atomic." >>>>>>>>> >>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>> ARM and >>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>> current issue is what you wrote below: >>>>>>>>> >>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>> (parse3.cpp:320) >>>>>>>>> > and place it before loads. >>>>>>>>> >>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>> after >>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>> same >>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>> load - >>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>> clearer. >>>>>>>>> >>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>> implemented as >>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>> hooks >>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>> this >>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>> >>>>>>>>>> I did not yet add the >>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> or >>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>> >>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>> >>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>> store >>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>> (volatile store in constructor). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> @David >>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>> continuous. >>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>> issue. >>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>> you >>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>> solution, >>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>> issues. >>>>>>>>>> >>>>>>>>>> @David >>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>> and >>>>>>>>>>> can't find any reference to it. >>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>> ARM and >>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>> Work-Stealing for >>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>> taskqueue problem. >>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>> >>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>> used 'read' >>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>> above). >>>>>>>>>> >>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>> processors >>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>> Aleksey!) >>>>>>>>>> >>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>> >>>>>>>>>>> -- IRIW issue >>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>> a few >>>>>>>>>>>> moments thought. >>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>> problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>>> >>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>> different?) >>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>> I contributed a >>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>> nice, I admit. >>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>> are evaluated >>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>> >>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>> problem >>>>>>>>>>> is that >>>>>>>>>>> store >>>>>>>>>>> sync >>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>> only >>>>>>>>>>> sync >>>>>>>>>>> load >>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>> pass that test. >>>>>>>>>> >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>> term and >>>>>>>>>> can't find any reference to it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> The JMM is fine. And >>>>>>>>>>> store >>>>>>>>>>> MemBarVolatile >>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>> that >>>>>>>>>>> do what is required. >>>>>>>>>>> >>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi everybody, >>>>>>>>>>>> >>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>> >>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>> initializing >>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>> Shipilev >>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>> will fail. >>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>> volatile field would be >>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>> >>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>> volatiles do >>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>> that >>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>> Aleksey >>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>>> >>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>> heavyweight >>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>> don't >>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>> >>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>> account >>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>> different platforms >>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>> An example: >>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>> this: >>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>> fine grained operations: >>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>> can not implement >>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>> >>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>> issue. >>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>> read >>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>> >>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>> independent? >>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>> >>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>> few >>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>> will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>> moment. The >>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>> requirements for >>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>> are not >>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>> store >>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>> of the >>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>> software >>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>> don't have >>>>>>>>>>> that on ppc!) >>>>>>>>>>> >>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>> I will >>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> -- Other ports: >>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>> it might >>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>> them). >>>>>>>>>>>> >>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>> can >>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>> way :) >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>> >>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>> fix an >>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>> IRIW >>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>> doing the >>>>>>>>>>>> load. >>>>>>>>>>>> >>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>> would be >>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>> performance >>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>> that >>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>> this is >>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>> with the >>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>> the >>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>> properties >>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>> on a >>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>> reduce >>>>>>>>>>>> to a no-op. >>>>>>>>>>>> >>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>> under >>>>>>>>>>>> the JMM. >>>>>>>>>>>> >>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>> current >>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>> is set >>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>> >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>> >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>> Java >>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>> explicitly >>>>>>>>>>>> like this. >>>>>>>>>>>> >>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>> there >>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>> defines? >>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>> David? >>>>>>>>>>>> >>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>> >>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>> specific which >>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>> >>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>> >>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>> #else >>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>> volatile field >>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>> } >>>>>>>>>>>>> #endif >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Example: >>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>> >>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>> is only >>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>> threads >>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>> fields >>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>> published. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>> seems too >>>>>>>>>>>>>> strong. >>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Tue Jan 21 05:19:28 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Jan 2014 13:19:28 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52DE5FB0.5000808@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> Sorry, I missed that. fixed. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 21. Januar 2014 12:53 To: Lindenmaier, Goetz; Vladimir Kozlov Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Thanks Goetz! This typo still exists: + bool _wrote_volatile; // Did we write a final field? s/final/volatile/ Otherwise no further comments from me. David On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: > Hi, > > I made a new webrev > http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ > differing from > http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ > only in the comments. > > I removed > // Support ordering of "Independent Reads of Independent Writes". > everywhere, and edited the comments in the globalDefinition*.hpp > files. > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 21. Januar 2014 05:55 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I tried to come up with a webrev that implements the change as proposed in >> your mails: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >> >> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >> support_IRIW_for_not_multiple_copy_atomic_cpu. > > Given the flag name the commentary eg: > > + // Support ordering of "Independent Reads of Independent Writes". > + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { > > seems somewhat redundant. > >> I left the definition and handling of _wrote_volatile in the code, without >> any protection. > > + bool _wrote_volatile; // Did we write a final field? > > s/final/volatile > >> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >> and put it on one line. >> >> I removed the comment in library_call.cpp. >> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >> from the comments as it's PPC specific. > > I think the primary IRIW comment/explanation should go in > globalDefinitions.hpp where > support_IRIW_for_not_multiple_copy_atomic_cpu is defined. > >> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >> issues in C1 if nobody did it by then. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8032366 > > "Implement C1 support for IRIW conformance on non-multiple-copy-atomic > platforms" > > to cover this task, as it may be needed sooner rather than later. > >> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >> performance problems arise, we still can add #ifdef PPC64 to circumvent this. > > Ok. > > Thanks, > David > >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 16. Januar 2014 10:05 >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>> On 1/16/14 12:34 AM, David Holmes wrote: >>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>> want to keep it this way, it could be useful to have such info on other >>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>> parse.hpp. >>>>> >>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>> which could be checked in all places instead of #ifdef: >>>> >>>> I asked for the ifdef some time back as I find it much preferable to >>>> have this as a build-time construct rather than a >>>> runtime one. I don't want to have to pay anything for this if we don't >>>> use it. >>> >>> Any decent C++ compiler will optimize expressions with such constants >>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >> >> If you insist then we may as well do it all the same way. Better to be >> consistent. >> >> My apologies Goetz for wasting your time going back and forth on this. >> >> That aside I have a further concern with this IRIW support - it is >> incomplete as there is no C1 support, as PPC64 isn't using client. If >> this is going on then we (which probably means the Oracle 'we') need to >> add the missing C1 code. >> >> David >> ----- >> >>> Vladimir >>> >>>> >>>> David >>>> >>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>> #else >>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>> #endif >>>>> >>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>> >>>>> and then: >>>>> >>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>> oop p = JNIHandles::resolve(obj); \ >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>> OrderAccess::fence(); \ >>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>> >>>>> And: >>>>> >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>> field->is_volatile()) { >>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>> + } >>>>> >>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>> >>>>> The code in parse1.cpp could be put on one line: >>>>> >>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>> method()->is_initializer()) )) { >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I updated the webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>> >>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>> volatile constructor issue, but that it's not standard. >>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>> I also think it's better to separate these this way. >>>>>> >>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>> please. >>>>>> >>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>> comment doesn't make much sense to me and refers to >>>>>> ppc specific stuff in a shared file: >>>>>> >>>>>> if (is_volatile) { >>>>>> ! if (!is_store) { >>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>> ! } else { >>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>> + #endif >>>>>> + } >>>>>> >>>>>> I don't think the comment is needed. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks for your comments! >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> Sorry for the delay in getting back to this. >>>>>>> >>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>> specifically it is >>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>> Seems >>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>> >>>>>>> The changes related to volatile writes in the constructor, as >>>>>>> discussed >>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>> PPC64 porters. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>> this version. >>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lindenmaier, Goetz >>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>> To: David Holmes >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>> not >>>>>>>>> required to pass. >>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>> worked >>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>> it by >>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>> part is >>>>>>>> not that performance relevant. >>>>>>>> >>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>> think >>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>> but this way I only have to change the ppc platform. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz >>>>>>>> >>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>> emails. >>>>>>>> >>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>> settled. >>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>> >>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>> The change is about IRIW. >>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>> >>>>>>>> This is the part I still have some question marks over as the >>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>> But I'm >>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>> >>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>> stores. >>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>> constructor tests. >>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>> after stores >>>>>>>>> to pass the volatile constructor tests. >>>>>>>> >>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>> were not >>>>>>>> required to pass. >>>>>>>> >>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>> order >>>>>>>>> instructions are not as find-granular as the >>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>> The only instruction >>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>> therefore the >>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>> proper representation >>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>> it's pointless >>>>>>>>> anyways. >>>>>>>>> >>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>> I'd be happy to add a property >>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>> >>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>> think >>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>> on/off for any architecture for testing purposes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>> Or also >>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> TL;DR version: >>>>>>>>> >>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>> constructor-barrier >>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>> *may* >>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>> ensure >>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>> invalid >>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>> need it >>>>>>>>> due to other factors). >>>>>>>>> >>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>> term :) >>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>> >>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>> visible to >>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>> architectures >>>>>>>>> are not multiple-copy atomic." >>>>>>>>> >>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>> ARM and >>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>> current issue is what you wrote below: >>>>>>>>> >>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>> (parse3.cpp:320) >>>>>>>>> > and place it before loads. >>>>>>>>> >>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>> after >>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>> same >>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>> load - >>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>> clearer. >>>>>>>>> >>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>> implemented as >>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>> hooks >>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>> >>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>> this >>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>> >>>>>>>>>> I did not yet add the >>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> or >>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>> >>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>> >>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>> store >>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>> (volatile store in constructor). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> @David >>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>> continuous. >>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>> issue. >>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>> you >>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>> solution, >>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>> issues. >>>>>>>>>> >>>>>>>>>> @David >>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>> and >>>>>>>>>>> can't find any reference to it. >>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>> ARM and >>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>> Work-Stealing for >>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>> taskqueue problem. >>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>> >>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>> used 'read' >>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>> above). >>>>>>>>>> >>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>> processors >>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>> Aleksey!) >>>>>>>>>> >>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>> >>>>>>>>>>> -- IRIW issue >>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>> a few >>>>>>>>>>>> moments thought. >>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>> problem yet, >>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>> >>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>> continuous. >>>>>>>>>> >>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>> different?) >>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>> I contributed a >>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>> nice, I admit. >>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>> are evaluated >>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>> >>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>> problem >>>>>>>>>>> is that >>>>>>>>>>> store >>>>>>>>>>> sync >>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>> only >>>>>>>>>>> sync >>>>>>>>>>> load >>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>> pass that test. >>>>>>>>>> >>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>> term and >>>>>>>>>> can't find any reference to it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> The JMM is fine. And >>>>>>>>>>> store >>>>>>>>>>> MemBarVolatile >>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>> that >>>>>>>>>>> do what is required. >>>>>>>>>>> >>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi everybody, >>>>>>>>>>>> >>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>> >>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>> initializing >>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>> Shipilev >>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>> will fail. >>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>> volatile field would be >>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>> >>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>> volatiles do >>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>> that >>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>> Aleksey >>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>> missing constructor barrier. >>>>>>>>>>> >>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>> heavyweight >>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>> don't >>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>> >>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>> account >>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>> different platforms >>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>> An example: >>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>> this: >>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>> fine grained operations: >>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>> can not implement >>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>> >>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>> issue. >>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>> read >>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>> >>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>> independent? >>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>> >>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>> few >>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>> will >>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>> moment. The >>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>> requirements for >>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>> are not >>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>> store >>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>> of the >>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>> software >>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>> don't have >>>>>>>>>>> that on ppc!) >>>>>>>>>>> >>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>> I will >>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> -- Other ports: >>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>> it might >>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>> them). >>>>>>>>>>>> >>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>> can >>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>> way :) >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>> >>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>> fix an >>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>> IRIW >>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>> doing the >>>>>>>>>>>> load. >>>>>>>>>>>> >>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>> would be >>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>> performance >>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>> that >>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>> this is >>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>> with the >>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>> the >>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>> properties >>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>> on a >>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>> reduce >>>>>>>>>>>> to a no-op. >>>>>>>>>>>> >>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>> under >>>>>>>>>>>> the JMM. >>>>>>>>>>>> >>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>> current >>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>> is set >>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>> >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>> >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>> Java >>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>> explicitly >>>>>>>>>>>> like this. >>>>>>>>>>>> >>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>> there >>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>> defines? >>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>> David? >>>>>>>>>>>> >>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>> >>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>> specific which >>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>> >>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>> >>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>> #else >>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>> volatile field >>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>> } >>>>>>>>>>>>> #endif >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Example: >>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>> >>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>> is only >>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>> threads >>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>> fields >>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>> published. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>> seems too >>>>>>>>>>>>>> strong. >>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> From volker.simonis at gmail.com Tue Jan 21 09:49:07 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 Jan 2014 18:49:07 +0100 Subject: 7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X In-Reply-To: <52DD965A.1030505@oracle.com> References: <52DD10A1.3040202@oracle.com> <52DD965A.1030505@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 10:34 PM, Alan Bateman wrote: > On 20/01/2014 19:57, Volker Simonis wrote: >> >> Hi Alan, >> >> I've tried your patch with our port on AIX. >> The good news is that it fixes: >> >> java/nio/channels/AsynchronousFileChannel/Lock.java >> >> on AIX as well. >> >> The bad news is, that it doesn't seem to help for: >> >> java/nio/channels/AsyncCloseAndInterrupt.java >> >> Here's a stack trace of where the VM gets stuck: > > In these stack traces then the channels are Pipe.SourceChannel or > Pipe.SinkChannel where the file descriptor is to one end of a pipe. Are > these the only cases where you see these hangs? I'm interested to know if > the async close of SocketChannel and ServerSocketChannel when configured > blocked also hangs (I will guess that it will as the behavior is likely to > be the same as pipe). I also think they will hang, but I'm not sure how to test it. The java/nio/channels/AsynchronousServerSocketChannel and java/nio/channels/AsynchronousSocketChannel all pass, but I'm not sure if they test the same thing. In the NIO are, I currently (with your change) have problems with the following tests: java/nio/channels/AsyncCloseAndInterrupt.java (hangs) java/nio/channels/AsynchronousChannelGroup/Basic.java (hangs somtimes) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java (hangs) java/nio/channels/AsynchronousChannelGroup/Unbounded.java (hangs somtimes) java/nio/channels/Selector/RacyDeregister.java (fails) However, java/nio/channels/AsynchronousChannelGroup/Unbounded.java hangs in AixPollPort.pollset_poll() (which is our implementation of AsynchronousChannelGroup) so that may be a completely different problem. I'm currently try to debug it. > I have an idea on how to fix this so that the preClose isn't used when the > channel is configured blocking (or isn't registered with a Selector). The > patch doesn't use NativeThreadSet because it isn't efficient when the number > of threads is limited to 1 or 2 (FileChannel uses NativeThreadSet because it > defines positional read/write and so the number of concurrent reader/writers > is unlimited). > Yes, I'm definitely interested to see and test your patch on AIX. > I'll send a patch the other channels soon and we can see if this works for > you. If it does work then I have a bit of a preference to being it in via > jdk9/dev rather than via the AIX staging forest because the changes impact > all platforms. Yes, that's no problem. I think the class library for AIX will be fine and ready for integration into jdk9/dev without these changes. We can fix that later and backport it to 8u-dev as required. > That said, if we being this FileChannel fix for OSX in then > it means that the platform specific changes would be in, the patch for the > other platforms shouldn't require porting. > > -Alan. > From vladimir.kozlov at oracle.com Tue Jan 21 12:00:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jan 2014 12:00:18 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> Message-ID: <52DED1D2.1070203@oracle.com> Thanks. I am pushing it. Vladimir On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: > Sorry, I missed that. fixed. > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 21. Januar 2014 12:53 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Thanks Goetz! > > This typo still exists: > > + bool _wrote_volatile; // Did we write a final field? > > s/final/volatile/ > > Otherwise no further comments from me. > > David > > On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I made a new webrev >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >> differing from >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >> only in the comments. >> >> I removed >> // Support ordering of "Independent Reads of Independent Writes". >> everywhere, and edited the comments in the globalDefinition*.hpp >> files. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 21. Januar 2014 05:55 >> To: Lindenmaier, Goetz; Vladimir Kozlov >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I tried to come up with a webrev that implements the change as proposed in >>> your mails: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>> >>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>> support_IRIW_for_not_multiple_copy_atomic_cpu. >> >> Given the flag name the commentary eg: >> >> + // Support ordering of "Independent Reads of Independent Writes". >> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >> >> seems somewhat redundant. >> >>> I left the definition and handling of _wrote_volatile in the code, without >>> any protection. >> >> + bool _wrote_volatile; // Did we write a final field? >> >> s/final/volatile >> >>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>> and put it on one line. >>> >>> I removed the comment in library_call.cpp. >>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>> from the comments as it's PPC specific. >> >> I think the primary IRIW comment/explanation should go in >> globalDefinitions.hpp where >> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >> >>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>> issues in C1 if nobody did it by then. >> >> I've filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8032366 >> >> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >> platforms" >> >> to cover this task, as it may be needed sooner rather than later. >> >>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >> >> Ok. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 16. Januar 2014 10:05 >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>> want to keep it this way, it could be useful to have such info on other >>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>> parse.hpp. >>>>>> >>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>> which could be checked in all places instead of #ifdef: >>>>> >>>>> I asked for the ifdef some time back as I find it much preferable to >>>>> have this as a build-time construct rather than a >>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>> use it. >>>> >>>> Any decent C++ compiler will optimize expressions with such constants >>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>> >>> If you insist then we may as well do it all the same way. Better to be >>> consistent. >>> >>> My apologies Goetz for wasting your time going back and forth on this. >>> >>> That aside I have a further concern with this IRIW support - it is >>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>> this is going on then we (which probably means the Oracle 'we') need to >>> add the missing C1 code. >>> >>> David >>> ----- >>> >>>> Vladimir >>>> >>>>> >>>>> David >>>>> >>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>> #else >>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>> #endif >>>>>> >>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>> >>>>>> and then: >>>>>> >>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>> OrderAccess::fence(); \ >>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>> >>>>>> And: >>>>>> >>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>> field->is_volatile()) { >>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>> + } >>>>>> >>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>> >>>>>> The code in parse1.cpp could be put on one line: >>>>>> >>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>> method()->is_initializer()) )) { >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I updated the webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> >>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>> I also think it's better to separate these this way. >>>>>>> >>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>> please. >>>>>>> >>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>> comment doesn't make much sense to me and refers to >>>>>>> ppc specific stuff in a shared file: >>>>>>> >>>>>>> if (is_volatile) { >>>>>>> ! if (!is_store) { >>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>> ! } else { >>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>> + #endif >>>>>>> + } >>>>>>> >>>>>>> I don't think the comment is needed. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks for your comments! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> Sorry for the delay in getting back to this. >>>>>>>> >>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>> specifically it is >>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>> Seems >>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>> >>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>> discussed >>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>> PPC64 porters. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>> this version. >>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>> To: David Holmes >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>> not >>>>>>>>>> required to pass. >>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>> worked >>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>> it by >>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>> part is >>>>>>>>> not that performance relevant. >>>>>>>>> >>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>> think >>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz >>>>>>>>> >>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>> emails. >>>>>>>>> >>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>> settled. >>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>> >>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>> The change is about IRIW. >>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>> >>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>> But I'm >>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>> >>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>> stores. >>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>> constructor tests. >>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>> after stores >>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>> >>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>> were not >>>>>>>>> required to pass. >>>>>>>>> >>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>> order >>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>> The only instruction >>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>> therefore the >>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>> proper representation >>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>> it's pointless >>>>>>>>>> anyways. >>>>>>>>>> >>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>> I'd be happy to add a property >>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>> >>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>> think >>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>> Or also >>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> TL;DR version: >>>>>>>>>> >>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>> constructor-barrier >>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>> *may* >>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>> ensure >>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>> invalid >>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>> need it >>>>>>>>>> due to other factors). >>>>>>>>>> >>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>> term :) >>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>> >>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>> visible to >>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>> architectures >>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>> >>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>> ARM and >>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>> current issue is what you wrote below: >>>>>>>>>> >>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>> (parse3.cpp:320) >>>>>>>>>> > and place it before loads. >>>>>>>>>> >>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>> after >>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>> same >>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>> load - >>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>> clearer. >>>>>>>>>> >>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>> implemented as >>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>> hooks >>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>> >>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>> this >>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>> >>>>>>>>>>> I did not yet add the >>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> or >>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>> >>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>> >>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>> store >>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @David >>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>> continuous. >>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>> issue. >>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>> you >>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>> solution, >>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>> issues. >>>>>>>>>>> >>>>>>>>>>> @David >>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>> and >>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>> ARM and >>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>> Work-Stealing for >>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>> taskqueue problem. >>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>> >>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>> used 'read' >>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>> above). >>>>>>>>>>> >>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>> processors >>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>> Aleksey!) >>>>>>>>>>> >>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>> >>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>> a few >>>>>>>>>>>>> moments thought. >>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>> problem yet, >>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>> >>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>> continuous. >>>>>>>>>>> >>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>> different?) >>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>> I contributed a >>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>> nice, I admit. >>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>> are evaluated >>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>> >>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>> problem >>>>>>>>>>>> is that >>>>>>>>>>>> store >>>>>>>>>>>> sync >>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>> only >>>>>>>>>>>> sync >>>>>>>>>>>> load >>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>> pass that test. >>>>>>>>>>> >>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>> term and >>>>>>>>>>> can't find any reference to it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>> store >>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>> that >>>>>>>>>>>> do what is required. >>>>>>>>>>>> >>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>> >>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>> initializing >>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>> Shipilev >>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>> will fail. >>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>> >>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>> volatiles do >>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>> that >>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>> Aleksey >>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>> >>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>> don't >>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>> >>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>> account >>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>> different platforms >>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>> An example: >>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>> this: >>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>> can not implement >>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>> >>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>> issue. >>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>> read >>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>> >>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>> independent? >>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>> >>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>> few >>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>> will >>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>> moment. The >>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>> requirements for >>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>> are not >>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>> store >>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>> of the >>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>> software >>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>> don't have >>>>>>>>>>>> that on ppc!) >>>>>>>>>>>> >>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>> I will >>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>> it might >>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>> them). >>>>>>>>>>>>> >>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>> can >>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>> way :) >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>> >>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>> fix an >>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>> IRIW >>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>> doing the >>>>>>>>>>>>> load. >>>>>>>>>>>>> >>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>> would be >>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>> performance >>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>> that >>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>> this is >>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>> with the >>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>> the >>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>> properties >>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>> on a >>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>> reduce >>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>> >>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>> under >>>>>>>>>>>>> the JMM. >>>>>>>>>>>>> >>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>> current >>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>> is set >>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>> >>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>> >>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>> >>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>> Java >>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>> explicitly >>>>>>>>>>>>> like this. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>> there >>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>> defines? >>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>> David? >>>>>>>>>>>>> >>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>> specific which >>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>> #else >>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> #endif >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> From Alan.Bateman at oracle.com Tue Jan 21 12:41:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jan 2014 20:41:03 +0000 Subject: 7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X In-Reply-To: References: <52DD10A1.3040202@oracle.com> <52DD965A.1030505@oracle.com> Message-ID: <52DEDB5F.6050301@oracle.com> On 21/01/2014 17:49, Volker Simonis wrote: > : > I also think they will hang, but I'm not sure how to test it. The > java/nio/channels/AsynchronousServerSocketChannel and > java/nio/channels/AsynchronousSocketChannel all pass, but I'm not sure > if they test the same thing. > > In the NIO are, I currently (with your change) have problems with the > following tests: > > java/nio/channels/AsyncCloseAndInterrupt.java (hangs) > java/nio/channels/AsynchronousChannelGroup/Basic.java (hangs somtimes) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java (hangs) > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (hangs somtimes) > java/nio/channels/Selector/RacyDeregister.java (fails) > > However, java/nio/channels/AsynchronousChannelGroup/Unbounded.java > hangs in AixPollPort.pollset_poll() (which is our implementation of > AsynchronousChannelGroup) so that may be a completely different > problem. I'm currently try to debug it. The SelectableChannel and AsynchronousChannel implementations are very different. In the SelectableChannel implementations then closing is complicated due to the possibility of threads being blocked in I/O operations. From the mails then it is clear that AIX hangs in dup2 but an alternative approach to initially signal the blocked threads should work there. One of the reasons for not agreeing to the calling into the NET_* function is that it results in double accounting, the selectable channels already track it. I'll send a patch soon to try and we can see about resolving this once the changes are in jdk9/dev. On testing it then AsyncCloseAndInterrupt will close and interrupt on each of the channels so it is a useful test. I don't know what to say about the AsynchronousChannelGroup tests that are hanging, I think I'd need to see the full stack trace. Closing of these channels is cooperative as there isn't any blocking so it's much simpler. So is portset_poll your implementation of Port.startPoll? > : > Yes, that's no problem. I think the class library for AIX will be fine > and ready for integration into jdk9/dev without these changes. We can > fix that later and backport it to 8u-dev as required. I think this makes sense. -Alan. From vladimir.kozlov at oracle.com Tue Jan 21 16:10:23 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 22 Jan 2014 00:10:23 +0000 Subject: hg: ppc-aix-port/stage-9/hotspot: 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Message-ID: <20140122001025.F3D4162629@hg.openjdk.java.net> Changeset: c6d7e7406136 Author: goetz Date: 2014-01-16 14:25 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/c6d7e7406136 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Reviewed-by: dholmes, kvn Contributed-by: martin.doerr at sap.com ! src/cpu/ppc/vm/globalDefinitions_ppc.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/utilities/globalDefinitions.hpp From goetz.lindenmaier at sap.com Wed Jan 22 01:20:47 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Jan 2014 09:20:47 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52DED1D2.1070203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> Hi Vladimir, Thanks for testing and pushing! Will you push this also to stage? I assume we can handle this as the other three hotspot changes, without a new bug-id? Also, when do you think we (you unfortunately) should update the repos again? Stage-9 maybe after Volkers last change is submitted? Best regards, Goetz -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Dienstag, 21. Januar 2014 21:00 Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Thanks. I am pushing it. Vladimir On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: > Sorry, I missed that. fixed. > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 21. Januar 2014 12:53 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Thanks Goetz! > > This typo still exists: > > + bool _wrote_volatile; // Did we write a final field? > > s/final/volatile/ > > Otherwise no further comments from me. > > David > > On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I made a new webrev >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >> differing from >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >> only in the comments. >> >> I removed >> // Support ordering of "Independent Reads of Independent Writes". >> everywhere, and edited the comments in the globalDefinition*.hpp >> files. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 21. Januar 2014 05:55 >> To: Lindenmaier, Goetz; Vladimir Kozlov >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I tried to come up with a webrev that implements the change as proposed in >>> your mails: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>> >>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>> support_IRIW_for_not_multiple_copy_atomic_cpu. >> >> Given the flag name the commentary eg: >> >> + // Support ordering of "Independent Reads of Independent Writes". >> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >> >> seems somewhat redundant. >> >>> I left the definition and handling of _wrote_volatile in the code, without >>> any protection. >> >> + bool _wrote_volatile; // Did we write a final field? >> >> s/final/volatile >> >>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>> and put it on one line. >>> >>> I removed the comment in library_call.cpp. >>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>> from the comments as it's PPC specific. >> >> I think the primary IRIW comment/explanation should go in >> globalDefinitions.hpp where >> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >> >>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>> issues in C1 if nobody did it by then. >> >> I've filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8032366 >> >> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >> platforms" >> >> to cover this task, as it may be needed sooner rather than later. >> >>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >> >> Ok. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 16. Januar 2014 10:05 >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>> want to keep it this way, it could be useful to have such info on other >>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>> parse.hpp. >>>>>> >>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>> which could be checked in all places instead of #ifdef: >>>>> >>>>> I asked for the ifdef some time back as I find it much preferable to >>>>> have this as a build-time construct rather than a >>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>> use it. >>>> >>>> Any decent C++ compiler will optimize expressions with such constants >>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>> >>> If you insist then we may as well do it all the same way. Better to be >>> consistent. >>> >>> My apologies Goetz for wasting your time going back and forth on this. >>> >>> That aside I have a further concern with this IRIW support - it is >>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>> this is going on then we (which probably means the Oracle 'we') need to >>> add the missing C1 code. >>> >>> David >>> ----- >>> >>>> Vladimir >>>> >>>>> >>>>> David >>>>> >>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>> #else >>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>> #endif >>>>>> >>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>> >>>>>> and then: >>>>>> >>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>> OrderAccess::fence(); \ >>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>> >>>>>> And: >>>>>> >>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>> field->is_volatile()) { >>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>> + } >>>>>> >>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>> >>>>>> The code in parse1.cpp could be put on one line: >>>>>> >>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>> method()->is_initializer()) )) { >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I updated the webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>> >>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>> I also think it's better to separate these this way. >>>>>>> >>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>> please. >>>>>>> >>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>> comment doesn't make much sense to me and refers to >>>>>>> ppc specific stuff in a shared file: >>>>>>> >>>>>>> if (is_volatile) { >>>>>>> ! if (!is_store) { >>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>> ! } else { >>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>> + #endif >>>>>>> + } >>>>>>> >>>>>>> I don't think the comment is needed. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks for your comments! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>> Independent Reads of Independent Writes >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> Sorry for the delay in getting back to this. >>>>>>>> >>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>> specifically it is >>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>> Seems >>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>> >>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>> discussed >>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>> PPC64 porters. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>> this version. >>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>> To: David Holmes >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>> not >>>>>>>>>> required to pass. >>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>> worked >>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>> it by >>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>> part is >>>>>>>>> not that performance relevant. >>>>>>>>> >>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>> think >>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz >>>>>>>>> >>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>> emails. >>>>>>>>> >>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>> settled. >>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>> >>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>> The change is about IRIW. >>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>> >>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>> But I'm >>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>> >>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>> stores. >>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>> constructor tests. >>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>> after stores >>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>> >>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>> were not >>>>>>>>> required to pass. >>>>>>>>> >>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>> order >>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>> The only instruction >>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>> therefore the >>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>> proper representation >>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>> it's pointless >>>>>>>>>> anyways. >>>>>>>>>> >>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>> I'd be happy to add a property >>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>> >>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>> think >>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>> Or also >>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> TL;DR version: >>>>>>>>>> >>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>> constructor-barrier >>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>> *may* >>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>> ensure >>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>> invalid >>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>> need it >>>>>>>>>> due to other factors). >>>>>>>>>> >>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>> term :) >>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>> >>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>> visible to >>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>> architectures >>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>> >>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>> ARM and >>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>> current issue is what you wrote below: >>>>>>>>>> >>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>> (parse3.cpp:320) >>>>>>>>>> > and place it before loads. >>>>>>>>>> >>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>> after >>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>> same >>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>> load - >>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>> clearer. >>>>>>>>>> >>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>> implemented as >>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>> hooks >>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>> >>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>> this >>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>> >>>>>>>>>>> I did not yet add the >>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> or >>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>> >>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>> >>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>> store >>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @David >>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>> continuous. >>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>> issue. >>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>> you >>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>> solution, >>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>> issues. >>>>>>>>>>> >>>>>>>>>>> @David >>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>> and >>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>> ARM and >>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>> Work-Stealing for >>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>> taskqueue problem. >>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>> >>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>> used 'read' >>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>> above). >>>>>>>>>>> >>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>> processors >>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>> Aleksey!) >>>>>>>>>>> >>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>> >>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>> a few >>>>>>>>>>>>> moments thought. >>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>> problem yet, >>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>> >>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>> continuous. >>>>>>>>>>> >>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>> different?) >>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>> I contributed a >>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>> nice, I admit. >>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>> are evaluated >>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>> >>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>> problem >>>>>>>>>>>> is that >>>>>>>>>>>> store >>>>>>>>>>>> sync >>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>> only >>>>>>>>>>>> sync >>>>>>>>>>>> load >>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>> pass that test. >>>>>>>>>>> >>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>> term and >>>>>>>>>>> can't find any reference to it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>> store >>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>> that >>>>>>>>>>>> do what is required. >>>>>>>>>>>> >>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>> >>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>> initializing >>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>> Shipilev >>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>> will fail. >>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>> >>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>> volatiles do >>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>> that >>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>> Aleksey >>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>> >>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>> don't >>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>> >>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>> account >>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>> different platforms >>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>> An example: >>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>> this: >>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>> can not implement >>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>> >>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>> issue. >>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>> read >>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>> >>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>> independent? >>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>> >>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>> few >>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>> will >>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>> moment. The >>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>> requirements for >>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>> are not >>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>> store >>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>> of the >>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>> software >>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>> don't have >>>>>>>>>>>> that on ppc!) >>>>>>>>>>>> >>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>> I will >>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>> it might >>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>> them). >>>>>>>>>>>>> >>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>> can >>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>> way :) >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>> >>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>> fix an >>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>> IRIW >>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>> doing the >>>>>>>>>>>>> load. >>>>>>>>>>>>> >>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>> would be >>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>> performance >>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>> that >>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>> this is >>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>> with the >>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>> the >>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>> properties >>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>> on a >>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>> reduce >>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>> >>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>> under >>>>>>>>>>>>> the JMM. >>>>>>>>>>>>> >>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>> current >>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>> is set >>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>> >>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>> >>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>> >>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>> Java >>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>> explicitly >>>>>>>>>>>>> like this. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>> there >>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>> defines? >>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>> David? >>>>>>>>>>>>> >>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>> specific which >>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>> #else >>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> #endif >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Wed Jan 22 06:01:14 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Jan 2014 14:01:14 +0000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <52DDE01D.1060605@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> <52DC8DA9.2010106@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap> <52DDE01D.1060605@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F125@DEWDFEMB12A.global.corp.sap> Hi, thanks for the hint to this paper, David! We modified the known read-after-write test to use the serialization page mechanism, and reading that paper we were able to understand it is correct on X86 / TSO. Thanks to Andreas Schoesser for this. http://cr.openjdk.java.net/~goetz/raw_serialization_page/raw_s11n_page.cpp We ran the test on linux ppc and aix over the weekend, without failure. This indicates the mechanism works there, too. The test fails immediately if the "write" in the fast thread is omitted. We also checked that both threads make considerable progress, and the fast thread does not always trap. Also, we looked at documentation about how mprotect etc should be implemented on ppc. A mprotect should do a tlbie, invidating the TLBs of all processors. It also should do an eieio and a tlbsync This assures the TLB of the "fast" process doing only the write is invalidated before mprotect returns. So the fast thread will experience a TLB-miss on the write. We assume on the TLB-miss some synchronization instruction is used, probably the ptesync. This should assure the fast thread gets the new value even if the page is already writable again. Unfortunately this is implemented in supervisor code, which is not available to us. I'll add a patch that enables UseMembar in our VM to test the performance impacts of that variant. As I don't see a good reason this flag is product, I'll change it to debug for the test. As you described, the flag should be set depending on whether the serialization page works. So nowadays it serves as a platform configuration so I think debug is the better choice. (Btw, you could move UsePPCLWSYNC into your globals_ppc.hpp with the new platform-dependent flags.) Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 21. Januar 2014 03:49 To: Lindenmaier, Goetz; Vladimir Kozlov Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization On 20/01/2014 11:41 PM, Lindenmaier, Goetz wrote: > Hi David, > > I understand your arguments and basically agree with them. > If the serialization page does not work on PPC, your solution > 1) is best. > > But I'm not sure why there should be a link between TSO and whether > the serialization page trick works. Second depends, as you say, > on the OS implementation. My limited understanding is that on RMO-based systems the requirements for: "Synchronization based on page-protections - mprotect()" as described in: http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt may not always hold. Dave Dice would need to provide more details if needed. Cheers, David > I would assume that the write to the serialization page causes > the OS to generate a new TLB entry or the like, involving the > use of a ptwsync instruction which would be fine. But we are > investigating this. > > We are also experimenting with a small regression test to find > out whether the serialization page ever fails. > > Best regards, > Goetz. > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 20. Januar 2014 03:45 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' > Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization > > On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I had a look at the first part of this issue: Whether StoreStore >> is necessary in the interpreter. Let's for now assume the serialization >> page mechanism works on PPC. >> >> In the state transition leaving the VM state, which is executed in the >> destructor, ThreadStateTransition::transition() is called, which executes >> if (UseMembar) { >> OrderAccess::fence(); >> } else { >> os::write_memory_serialize_page(thread); >> } >> >> os:: write_memory_serialize_page() can not be considered a proper >> MemBar, as it only serializes if another thread poisoned the page. >> Thus it does not qualify to order the initialization and the publishing >> of the object. >> >> You are right, if UseMembar is true, the StoreStore in the interpreter >> is superfluous. We could guard the StoreStores in the interpreter by >> !UseMembar. > > My understanding, from our existing non-TSO system ports, is that the > present assumption is that either: > > a) you have a TSO system, in which case you are probably using the > serialization page, but you don't need any barrier to enforce ordering > anyway; or > > b) you don't have a TSO system, you are using UseMembar==true and so you > get a full fence inserted that enforces the ordering anyway. > > So the ordering requirements are satisfied by piggy-backing on the > UseMembar setting that comes from the thread state transition code, > which forms part of the "runtime entry" code. That's not to say that you > will necessarily find this applied consistently in all places where it > might be applied - nor will you necessarily find that this is common > knowledge amongst VM engineers. > > Technically the storeStore barriers could be conditional on !UseMembar > but that is redundant in the current usage. > >> But then again, one is to order the publishing of the thread states, >> the other to enforce some Java semantics. I don't know whether everybody >> who changes in one place is aware of both issues. But if you want to, >> I'll add a !UseMembar in the interpreter. > > Here are my preferred options in order: > > 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - > rely on the piggy-backing effect. > > 2. Conditionalize the new storeStore barriers on !UseMembar. This > unfortunately penalizes all platforms with a runtime check. > > 3. Add the storeStores unconditionally. This penalizes platforms that > set UseMembar==true as we will now get two fences at runtime. > > I know we're talking about the interpreter here so performance is not > exactly critical, but still ... > >> Maybe it would be a good idea >> to document the double use in interfaceSupport.cpp, too. And maybe >> add an assertion of some kind. > > interfaceSupport doesn't know that other code piggy-backs on the fact > state-transitions have full fences when UseMembar is true. If it is > documented anywhere it should be in the interpreter (and any other > places that makes the same assumption) - something like: > > // On non-TSO systems there can be additional ordering constraints > // between Java-level actions (such as allocation and constructor > // invocation) that in principle need explicit memory barriers. > // However, on many non-TSO systems the thread-state transition logic > // in the IRT_ENTRY code will insert a full fence due to the use of > // UseMembar==true, which provides the necessary ordering guarantees. > >> >> We're digging into the other issue currenty, whether the serialization page >> works on ppc. We understand your concerns and have no simple answer to >> it right now. At least, in our VM and in the port there are no known problems >> with the state transitions. > > Even if the memory serialization page does not work, in a guaranteed > sense, on PPC-AIX, it is extremely unlikely that testing would expose > this. Also note that the memory serialization page behaviour is more a > function of the OS - so it may be that AIX is different to linux in that > regard. > > Cheers, > David > ----- > >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Donnerstag, 16. Januar 2014 19:16 >> To: David Holmes; Lindenmaier, Goetz >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' >> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization >> >> Changes are in C++ Interpreter so it does not affect Oracle VM. >> But David has point here. I would like to hear the explanation too. >> >> BTW, I see that for ppc64: >> >> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); >> >> as result write_memory_serialize_page() is used in >> ThreadStateTransition::transition(). >> >> Is it not enough on PPC64? >> >> Thanks, >> Vladimir >> >> On 1/15/14 9:30 PM, David Holmes wrote: >>> Can I get some response on this please - specifically the redundancy wrt >>> IRT_ENTRY actions. >>> >>> Thanks, >>> David >>> >>> On 20/12/2013 11:55 AM, David Holmes wrote: >>>> Still catching up ... >>>> >>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> this change adds StoreStore barriers after object initialization and >>>>> after constructor calls in the C++ interpreter. This assures no >>>>> uninitialized >>>>> objects or final fields are visible. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >>>> >>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >>>> thread state transitions that already include a full "fence" so the >>>> storestore barriers are redundant in those cases. >>>> >>>> The fastpath _new storestore seems okay. >>>> >>>> I don't know how handle_return gets used to know if it is reasonable or >>>> not. >>>> >>>> I was trying, unsuccessfully, to examine the same code in the >>>> templateInterpreter to see how it handles these cases as it naturally >>>> has the same object-initialization-safety requirements (though these can >>>> be handled in a number of different ways other than an unconditional >>>> storestore barrier at the end of the initialization and construction >>>> phases. >>>> >>>> David >>>> ----- >>>> >>>>> Please review and test this change. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From vladimir.kozlov at oracle.com Wed Jan 22 09:02:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 09:02:04 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> Message-ID: <52DFF98C.8010001@oracle.com> Hi Goetz On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Thanks for testing and pushing! > > Will you push this also to stage? I assume we can handle this > as the other three hotspot changes, without a new bug-id? Yes, I will backport it. What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581? Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix from jdk9. Or I am mistaking? > > Also, when do you think we (you unfortunately) should update > the repos again? Stage-9 maybe after Volkers last change is submitted? After I test and push 8031581 I will do sync with latest jdk9 sources (b01). I will build bundles and give them to SQE for final testing. Thanks, Vladimir > > Best regards, > Goetz > > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Dienstag, 21. Januar 2014 21:00 > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Thanks. I am pushing it. > > Vladimir > > On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >> Sorry, I missed that. fixed. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 21. Januar 2014 12:53 >> To: Lindenmaier, Goetz; Vladimir Kozlov >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Thanks Goetz! >> >> This typo still exists: >> >> + bool _wrote_volatile; // Did we write a final field? >> >> s/final/volatile/ >> >> Otherwise no further comments from me. >> >> David >> >> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I made a new webrev >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>> differing from >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>> only in the comments. >>> >>> I removed >>> // Support ordering of "Independent Reads of Independent Writes". >>> everywhere, and edited the comments in the globalDefinition*.hpp >>> files. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 21. Januar 2014 05:55 >>> To: Lindenmaier, Goetz; Vladimir Kozlov >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I tried to come up with a webrev that implements the change as proposed in >>>> your mails: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>> >>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>> >>> Given the flag name the commentary eg: >>> >>> + // Support ordering of "Independent Reads of Independent Writes". >>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>> >>> seems somewhat redundant. >>> >>>> I left the definition and handling of _wrote_volatile in the code, without >>>> any protection. >>> >>> + bool _wrote_volatile; // Did we write a final field? >>> >>> s/final/volatile >>> >>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>>> and put it on one line. >>>> >>>> I removed the comment in library_call.cpp. >>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>>> from the comments as it's PPC specific. >>> >>> I think the primary IRIW comment/explanation should go in >>> globalDefinitions.hpp where >>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>> >>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>>> issues in C1 if nobody did it by then. >>> >>> I've filed: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>> >>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >>> platforms" >>> >>> to cover this task, as it may be needed sooner rather than later. >>> >>>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >>> >>> Ok. >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>>> want to keep it this way, it could be useful to have such info on other >>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>> parse.hpp. >>>>>>> >>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>>> which could be checked in all places instead of #ifdef: >>>>>> >>>>>> I asked for the ifdef some time back as I find it much preferable to >>>>>> have this as a build-time construct rather than a >>>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>>> use it. >>>>> >>>>> Any decent C++ compiler will optimize expressions with such constants >>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>>> >>>> If you insist then we may as well do it all the same way. Better to be >>>> consistent. >>>> >>>> My apologies Goetz for wasting your time going back and forth on this. >>>> >>>> That aside I have a further concern with this IRIW support - it is >>>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>>> this is going on then we (which probably means the Oracle 'we') need to >>>> add the missing C1 code. >>>> >>>> David >>>> ----- >>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>> #else >>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>> #endif >>>>>>> >>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>> >>>>>>> and then: >>>>>>> >>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>> OrderAccess::fence(); \ >>>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>> >>>>>>> And: >>>>>>> >>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>> field->is_volatile()) { >>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>> + } >>>>>>> >>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>>> >>>>>>> The code in parse1.cpp could be put on one line: >>>>>>> >>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>> method()->is_initializer()) )) { >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> I updated the webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>> >>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>> I also think it's better to separate these this way. >>>>>>>> >>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>> please. >>>>>>>> >>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>> ppc specific stuff in a shared file: >>>>>>>> >>>>>>>> if (is_volatile) { >>>>>>>> ! if (!is_store) { >>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>> ! } else { >>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>> + #endif >>>>>>>> + } >>>>>>>> >>>>>>>> I don't think the comment is needed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks for your comments! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>> >>>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>>> specifically it is >>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>>> Seems >>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>>> >>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>> discussed >>>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>>> PPC64 porters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>>> this version. >>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>> To: David Holmes >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>>> not >>>>>>>>>>> required to pass. >>>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>>> worked >>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>>> it by >>>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>>> part is >>>>>>>>>> not that performance relevant. >>>>>>>>>> >>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>> think >>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz >>>>>>>>>> >>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>>> emails. >>>>>>>>>> >>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>>> settled. >>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>>> >>>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>>> The change is about IRIW. >>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>> >>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>>> But I'm >>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>> >>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>>> stores. >>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>> constructor tests. >>>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>>> after stores >>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>> >>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>> were not >>>>>>>>>> required to pass. >>>>>>>>>> >>>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>>> order >>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>>> The only instruction >>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>>> therefore the >>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>>> proper representation >>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>>> it's pointless >>>>>>>>>>> anyways. >>>>>>>>>>> >>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>> >>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>> think >>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>>> Or also >>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> TL;DR version: >>>>>>>>>>> >>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>> constructor-barrier >>>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>>> *may* >>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>>> ensure >>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>> invalid >>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>>> need it >>>>>>>>>>> due to other factors). >>>>>>>>>>> >>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>>> term :) >>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>> >>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>> visible to >>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>> architectures >>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>> >>>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>>> ARM and >>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>> >>>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>> > and place it before loads. >>>>>>>>>>> >>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>>> after >>>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>>> same >>>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>>> load - >>>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>>> clearer. >>>>>>>>>>> >>>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>> implemented as >>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>>> hooks >>>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>> >>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>>> this >>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>> >>>>>>>>>>>> I did not yet add the >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> or >>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>> >>>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>> >>>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>>> store >>>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> @David >>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>> continuous. >>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>>> issue. >>>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>>> you >>>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>>> solution, >>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>>> issues. >>>>>>>>>>>> >>>>>>>>>>>> @David >>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>>> and >>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>>> ARM and >>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>> >>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>>> used 'read' >>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>>> above). >>>>>>>>>>>> >>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>> processors >>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>> >>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>> >>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>>> a few >>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>>> problem yet, >>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>> >>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>> continuous. >>>>>>>>>>>> >>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>> different?) >>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>>> I contributed a >>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>>> are evaluated >>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>> problem >>>>>>>>>>>>> is that >>>>>>>>>>>>> store >>>>>>>>>>>>> sync >>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>> only >>>>>>>>>>>>> sync >>>>>>>>>>>>> load >>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>> pass that test. >>>>>>>>>>>> >>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>> term and >>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>> store >>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>>> that >>>>>>>>>>>>> do what is required. >>>>>>>>>>>>> >>>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>> initializing >>>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>> >>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>> volatiles do >>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>>> that >>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>>> Aleksey >>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>> >>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>>> don't >>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>>> account >>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>> An example: >>>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>>> this: >>>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>>> issue. >>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>>> read >>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>>> independent? >>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>> >>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>>> few >>>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>>> will >>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>> moment. The >>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>> requirements for >>>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>>> are not >>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>>> store >>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>>> of the >>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>>> software >>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>>> don't have >>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>>> I will >>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>>> it might >>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>>> them). >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>>> can >>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>>> way :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>>> fix an >>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>>> doing the >>>>>>>>>>>>>> load. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>> would be >>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>> performance >>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>>> that >>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>>> this is >>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>>> with the >>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>>> the >>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>> properties >>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>>> on a >>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>>> reduce >>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>>> under >>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>> >>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>>> Java >>>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>> like this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>>> there >>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>>> David? >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Wed Jan 22 09:20:13 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Jan 2014 17:20:13 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52DFF98C.8010001@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> <52DFF98C.8010001@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap> Hi Vladimir, > Yes, I will backport it. That's good, thank you! > I will build bundles and give them to SQE for final testing. __final__ That's even better, that's great!!! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 22. Januar 2014 18:02 To: Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi Goetz On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Thanks for testing and pushing! > > Will you push this also to stage? I assume we can handle this > as the other three hotspot changes, without a new bug-id? Yes, I will backport it. What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581? Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix from jdk9. Or I am mistaking? > > Also, when do you think we (you unfortunately) should update > the repos again? Stage-9 maybe after Volkers last change is submitted? After I test and push 8031581 I will do sync with latest jdk9 sources (b01). I will build bundles and give them to SQE for final testing. Thanks, Vladimir > > Best regards, > Goetz > > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Dienstag, 21. Januar 2014 21:00 > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Thanks. I am pushing it. > > Vladimir > > On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >> Sorry, I missed that. fixed. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 21. Januar 2014 12:53 >> To: Lindenmaier, Goetz; Vladimir Kozlov >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Thanks Goetz! >> >> This typo still exists: >> >> + bool _wrote_volatile; // Did we write a final field? >> >> s/final/volatile/ >> >> Otherwise no further comments from me. >> >> David >> >> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I made a new webrev >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>> differing from >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>> only in the comments. >>> >>> I removed >>> // Support ordering of "Independent Reads of Independent Writes". >>> everywhere, and edited the comments in the globalDefinition*.hpp >>> files. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 21. Januar 2014 05:55 >>> To: Lindenmaier, Goetz; Vladimir Kozlov >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I tried to come up with a webrev that implements the change as proposed in >>>> your mails: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>> >>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>> >>> Given the flag name the commentary eg: >>> >>> + // Support ordering of "Independent Reads of Independent Writes". >>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>> >>> seems somewhat redundant. >>> >>>> I left the definition and handling of _wrote_volatile in the code, without >>>> any protection. >>> >>> + bool _wrote_volatile; // Did we write a final field? >>> >>> s/final/volatile >>> >>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>>> and put it on one line. >>>> >>>> I removed the comment in library_call.cpp. >>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>>> from the comments as it's PPC specific. >>> >>> I think the primary IRIW comment/explanation should go in >>> globalDefinitions.hpp where >>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>> >>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>>> issues in C1 if nobody did it by then. >>> >>> I've filed: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>> >>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >>> platforms" >>> >>> to cover this task, as it may be needed sooner rather than later. >>> >>>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >>> >>> Ok. >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>>> want to keep it this way, it could be useful to have such info on other >>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>> parse.hpp. >>>>>>> >>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>>> which could be checked in all places instead of #ifdef: >>>>>> >>>>>> I asked for the ifdef some time back as I find it much preferable to >>>>>> have this as a build-time construct rather than a >>>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>>> use it. >>>>> >>>>> Any decent C++ compiler will optimize expressions with such constants >>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>>> >>>> If you insist then we may as well do it all the same way. Better to be >>>> consistent. >>>> >>>> My apologies Goetz for wasting your time going back and forth on this. >>>> >>>> That aside I have a further concern with this IRIW support - it is >>>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>>> this is going on then we (which probably means the Oracle 'we') need to >>>> add the missing C1 code. >>>> >>>> David >>>> ----- >>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>> #else >>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>> #endif >>>>>>> >>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>> >>>>>>> and then: >>>>>>> >>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>> OrderAccess::fence(); \ >>>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>> >>>>>>> And: >>>>>>> >>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>> field->is_volatile()) { >>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>> + } >>>>>>> >>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>>> >>>>>>> The code in parse1.cpp could be put on one line: >>>>>>> >>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>> method()->is_initializer()) )) { >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> I updated the webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>> >>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>> I also think it's better to separate these this way. >>>>>>>> >>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>> please. >>>>>>>> >>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>> ppc specific stuff in a shared file: >>>>>>>> >>>>>>>> if (is_volatile) { >>>>>>>> ! if (!is_store) { >>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>> ! } else { >>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>> + #endif >>>>>>>> + } >>>>>>>> >>>>>>>> I don't think the comment is needed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks for your comments! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>> Independent Reads of Independent Writes >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>> >>>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>>> specifically it is >>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>>> Seems >>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>>> >>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>> discussed >>>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>>> PPC64 porters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>>> this version. >>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>> To: David Holmes >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>>> not >>>>>>>>>>> required to pass. >>>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>>> worked >>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>>> it by >>>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>>> part is >>>>>>>>>> not that performance relevant. >>>>>>>>>> >>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>> think >>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz >>>>>>>>>> >>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>>> emails. >>>>>>>>>> >>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>>> settled. >>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>>> >>>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>>> The change is about IRIW. >>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>> >>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>>> But I'm >>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>> >>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>>> stores. >>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>> constructor tests. >>>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>>> after stores >>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>> >>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>> were not >>>>>>>>>> required to pass. >>>>>>>>>> >>>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>>> order >>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>>> The only instruction >>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>>> therefore the >>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>>> proper representation >>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>>> it's pointless >>>>>>>>>>> anyways. >>>>>>>>>>> >>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>> >>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>> think >>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>>> Or also >>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> TL;DR version: >>>>>>>>>>> >>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>> constructor-barrier >>>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>>> *may* >>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>>> ensure >>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>> invalid >>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>>> need it >>>>>>>>>>> due to other factors). >>>>>>>>>>> >>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>>> term :) >>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>> >>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>> visible to >>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>> architectures >>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>> >>>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>>> ARM and >>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>> >>>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>> > and place it before loads. >>>>>>>>>>> >>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>>> after >>>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>>> same >>>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>>> load - >>>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>>> clearer. >>>>>>>>>>> >>>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>> implemented as >>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>>> hooks >>>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>> >>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>>> this >>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>> >>>>>>>>>>>> I did not yet add the >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> or >>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>> >>>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>> >>>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>>> store >>>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> @David >>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>> continuous. >>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>>> issue. >>>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>>> you >>>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>>> solution, >>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>>> issues. >>>>>>>>>>>> >>>>>>>>>>>> @David >>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>>> and >>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>>> ARM and >>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>> >>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>>> used 'read' >>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>>> above). >>>>>>>>>>>> >>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>> processors >>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>> >>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>> >>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>>> a few >>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>>> problem yet, >>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>> >>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>> continuous. >>>>>>>>>>>> >>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>> different?) >>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>>> I contributed a >>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>>> are evaluated >>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>> problem >>>>>>>>>>>>> is that >>>>>>>>>>>>> store >>>>>>>>>>>>> sync >>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>> only >>>>>>>>>>>>> sync >>>>>>>>>>>>> load >>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>> pass that test. >>>>>>>>>>>> >>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>> term and >>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>> store >>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>>> that >>>>>>>>>>>>> do what is required. >>>>>>>>>>>>> >>>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>> initializing >>>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>> >>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>> volatiles do >>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>>> that >>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>>> Aleksey >>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>> >>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>>> don't >>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>>> account >>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>> An example: >>>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>>> this: >>>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>>> issue. >>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>>> read >>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>>> independent? >>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>> >>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>>> few >>>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>>> will >>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>> moment. The >>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>> requirements for >>>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>>> are not >>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>>> store >>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>>> of the >>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>>> software >>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>>> don't have >>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>>> I will >>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>>> it might >>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>>> them). >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>>> can >>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>>> way :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>>> fix an >>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>>> doing the >>>>>>>>>>>>>> load. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>> would be >>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>> performance >>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>>> that >>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>>> this is >>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>>> with the >>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>>> the >>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>> properties >>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>>> on a >>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>>> reduce >>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>>> under >>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>> >>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>>> Java >>>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>> like this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>>> there >>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>>> David? >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> From volker.simonis at gmail.com Wed Jan 22 09:42:18 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jan 2014 18:42:18 +0100 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52DFF98C.8010001@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6D7CA@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> <52DFF98C.8010001@oracle.com> Message-ID: On Wed, Jan 22, 2014 at 6:02 PM, Vladimir Kozlov wrote: > Hi Goetz > > > On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: >> >> Hi Vladimir, >> >> Thanks for testing and pushing! >> >> Will you push this also to stage? I assume we can handle this >> as the other three hotspot changes, without a new bug-id? > > > Yes, I will backport it. > > What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one > from today 8031581? > Should I backport all of them into 8u stage? From conversion between Volker > and Alan some of them need backport a fix from jdk9. Or I am mistaking? > It would be great if you could push 8028537, 8031134, 8031997 and 8031581 into 8u stage. There is no real source-code level dependency between these changes and the change "7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X)" which is still to be pushed by Alan to jdk9. However the AIX-port will automatically benefit from 7133499 once it will be pushed. > >> >> Also, when do you think we (you unfortunately) should update >> the repos again? Stage-9 maybe after Volkers last change is submitted? > > > After I test and push 8031581 I will do sync with latest jdk9 sources (b01). It would be great if you could push the change from: http://cr.openjdk.java.net/~simonis/webrevs/8031581_3 It is exactly the same like the one from http://cr.openjdk.java.net/~simonis/webrevs/8031581_2 with only one comment line changed to fix the typo "legel"->"legal" in src/share/native/java/util/zip/zip_util.c . Thanks a lot, Volker > I will build bundles and give them to SQE for final testing. > > Thanks, > Vladimir > > >> >> Best regards, >> Goetz >> >> >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Dienstag, 21. Januar 2014 21:00 >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >> Reads of Independent Writes >> >> Thanks. I am pushing it. >> >> Vladimir >> >> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >>> >>> Sorry, I missed that. fixed. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 21. Januar 2014 12:53 >>> To: Lindenmaier, Goetz; Vladimir Kozlov >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >>> Reads of Independent Writes >>> >>> Thanks Goetz! >>> >>> This typo still exists: >>> >>> + bool _wrote_volatile; // Did we write a final field? >>> >>> s/final/volatile/ >>> >>> Otherwise no further comments from me. >>> >>> David >>> >>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> I made a new webrev >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>>> differing from >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>> only in the comments. >>>> >>>> I removed >>>> // Support ordering of "Independent Reads of Independent Writes". >>>> everywhere, and edited the comments in the globalDefinition*.hpp >>>> files. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 21. Januar 2014 05:55 >>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >>>> Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>>> >>>>> Hi, >>>>> >>>>> I tried to come up with a webrev that implements the change as proposed >>>>> in >>>>> your mails: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>> >>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>>> >>>> >>>> Given the flag name the commentary eg: >>>> >>>> + // Support ordering of "Independent Reads of Independent >>>> Writes". >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>>> >>>> seems somewhat redundant. >>>> >>>>> I left the definition and handling of _wrote_volatile in the code, >>>>> without >>>>> any protection. >>>> >>>> >>>> + bool _wrote_volatile; // Did we write a final field? >>>> >>>> s/final/volatile >>>> >>>>> I protected issuing the barrier for volatile in constructors with >>>>> PPC64_ONLY() , >>>>> and put it on one line. >>>>> >>>>> I removed the comment in library_call.cpp. >>>>> I also removed the sentence " Solution: implement volatile read as >>>>> sync-load-acquire." >>>>> from the comments as it's PPC specific. >>>> >>>> >>>> I think the primary IRIW comment/explanation should go in >>>> globalDefinitions.hpp where >>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>>> >>>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we >>>>> will fix these >>>>> issues in C1 if nobody did it by then. >>>> >>>> >>>> I've filed: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>>> >>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >>>> platforms" >>>> >>>> to cover this task, as it may be needed sooner rather than later. >>>> >>>>> Wrt. to performance: Oracle will soon do heavy testing of the port. If >>>>> any >>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent >>>>> this. >>>> >>>> >>>> Ok. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >>>>> Reads of Independent Writes >>>>> >>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>>> >>>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>>> >>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>>>> want to keep it this way, it could be useful to have such info on >>>>>>>> other >>>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>>> parse.hpp. >>>>>>>> >>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a >>>>>>>> value >>>>>>>> which could be checked in all places instead of #ifdef: >>>>>>> >>>>>>> >>>>>>> I asked for the ifdef some time back as I find it much preferable to >>>>>>> have this as a build-time construct rather than a >>>>>>> runtime one. I don't want to have to pay anything for this if we >>>>>>> don't >>>>>>> use it. >>>>>> >>>>>> >>>>>> Any decent C++ compiler will optimize expressions with such constants >>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I >>>>>> really >>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>>>> >>>>> >>>>> If you insist then we may as well do it all the same way. Better to be >>>>> consistent. >>>>> >>>>> My apologies Goetz for wasting your time going back and forth on this. >>>>> >>>>> That aside I have a further concern with this IRIW support - it is >>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>>>> this is going on then we (which probably means the Oracle 'we') need to >>>>> add the missing C1 code. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>>> #else >>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>>> #endif >>>>>>>> >>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>>> >>>>>>>> and then: >>>>>>>> >>>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>>> OrderAccess::fence(); \ >>>>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>>> >>>>>>>> And: >>>>>>>> >>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>>> field->is_volatile()) { >>>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>>> + } >>>>>>>> >>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>>>> >>>>>>>> The code in parse1.cpp could be put on one line: >>>>>>>> >>>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>>> method()->is_initializer()) )) { >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> I updated the webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>> >>>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>>> reflect the new flagging. Also I mention that we support >>>>>>>>>> the >>>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>>> I also think it's better to separate these this way. >>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>>> please. >>>>>>>>> >>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>>> ppc specific stuff in a shared file: >>>>>>>>> >>>>>>>>> if (is_volatile) { >>>>>>>>> ! if (!is_store) { >>>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>>> ! } else { >>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, >>>>>>>>> sync-load-acquire. >>>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>>> + #endif >>>>>>>>> + } >>>>>>>>> >>>>>>>>> I don't think the comment is needed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks for your comments! >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>>> >>>>>>>>>> The general changes to the volatile barriers to support IRIW are >>>>>>>>>> okay. >>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though >>>>>>>>>> more >>>>>>>>>> specifically it is >>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much >>>>>>>>>> of >>>>>>>>>> the commentary excessive, particularly for shared code. In >>>>>>>>>> particular >>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give >>>>>>>>>> the >>>>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>>>> Seems >>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite >>>>>>>>>> adequate. >>>>>>>>>> >>>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>>> discussed >>>>>>>>>> are not required by the Java Memory Model. If you want to keep >>>>>>>>>> these >>>>>>>>>> then I think they should all be guarded with PPC64 because it is >>>>>>>>>> not >>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by >>>>>>>>>> the >>>>>>>>>> PPC64 porters. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I updated this webrev. I detected a small flaw I made when >>>>>>>>>>> editing >>>>>>>>>>> this version. >>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>>> To: David Holmes >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>>>> were >>>>>>>>>>>> not >>>>>>>>>>>> required to pass. >>>>>>>>>>> >>>>>>>>>>> We would prefer if we could keep this in. We want to avoid that >>>>>>>>>>> it's >>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>>>> worked >>>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would >>>>>>>>>>> guard >>>>>>>>>>> it by >>>>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, >>>>>>>>>>> this >>>>>>>>>>> part is >>>>>>>>>>> not that performance relevant. >>>>>>>>>>> >>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one >>>>>>>>>>>> I >>>>>>>>>>>> think >>>>>>>>>>> >>>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz >>>>>>>>>>> >>>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to >>>>>>>>>>> check >>>>>>>>>>> emails. >>>>>>>>>>> >>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>>>> settled. >>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the >>>>>>>>>>>> proof! >>>>>>>>>>>> >>>>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>>>> The change is about IRIW. >>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>>>> But I'm >>>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>>> >>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>>>> stores. >>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>>> constructor tests. >>>>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>>>> after stores >>>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>>> were not >>>>>>>>>>> required to pass. >>>>>>>>>>> >>>>>>>>>>>> We originally passed the constructor tests because the ppc >>>>>>>>>>>> memory >>>>>>>>>>>> order >>>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>>>> The only instruction >>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does >>>>>>>>>>>> StoreStore, >>>>>>>>>>>> therefore the >>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>>>> proper representation >>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But >>>>>>>>>>>> now >>>>>>>>>>>> it's pointless >>>>>>>>>>>> anyways. >>>>>>>>>>>> >>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>>> >>>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>> think >>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something >>>>>>>>>>> semantic >>>>>>>>>>> based not architecture based) as that will allows for turning >>>>>>>>>>> this >>>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> or the like to guard the customization. I'd like that much >>>>>>>>>>>> better. >>>>>>>>>>>> Or also >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> TL;DR version: >>>>>>>>>>>> >>>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>>> constructor-barrier >>>>>>>>>>>> for volatiles is not required as part of the JMM specification. >>>>>>>>>>>> It >>>>>>>>>>>> *may* >>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>>>> ensure >>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>>> invalid >>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>>>> need it >>>>>>>>>>>> due to other factors). >>>>>>>>>>>> >>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>>>> term :) >>>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>>> >>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and >>>>>>>>>>>> a >>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>>> visible to >>>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>>> architectures >>>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>>> >>>>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>>>> ARM and >>>>>>>>>>>> PPC. But of course it is normally handled by using suitable >>>>>>>>>>>> barriers >>>>>>>>>>>> after the stores that need to be visible. I think the crux of >>>>>>>>>>>> the >>>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>>> >>>>>>>>>>>> > The fixes for the constructor issue are only needed >>>>>>>>>>>> because we >>>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>>> > and place it before loads. >>>>>>>>>>>> >>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>>>> after >>>>>>>>>>>> the store then you have to do something around the loads to get >>>>>>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>> results! I still don't know what lead you to the conclusion that >>>>>>>>>>>> the >>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>>>> load - >>>>>>>>>>>> maybe when I get the chance to read that paper in full it will >>>>>>>>>>>> be >>>>>>>>>>>> clearer. >>>>>>>>>>>> >>>>>>>>>>>> So ... the basic problem is that the current structure in the VM >>>>>>>>>>>> has >>>>>>>>>>>> hard-wired one choice of how to get the right semantics for >>>>>>>>>>>> volatile >>>>>>>>>>>> variables. You now want to customize that but not all the >>>>>>>>>>>> requisite >>>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>>> implemented as >>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and >>>>>>>>>>>> post- >>>>>>>>>>>> hooks >>>>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>>> >>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I >>>>>>>>>>>> think >>>>>>>>>>>> this >>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The >>>>>>>>>>>> barrier >>>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> I did not yet add the >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>> or >>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the >>>>>>>>>>>>> JMM >>>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>>> >>>>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>>>> this a substantial task in implementing a PPC port. Also we >>>>>>>>>>>>> think >>>>>>>>>>>>> both tests show behavior a programmer would expect. It's bad >>>>>>>>>>>>> if >>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>>> >>>>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>>>> and place it before loads. Then there is no sync between >>>>>>>>>>>>> volatile >>>>>>>>>>>>> store >>>>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> @David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>>> continuous. >>>>>>>>>>>>> >>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on >>>>>>>>>>>>> this >>>>>>>>>>>>> issue. >>>>>>>>>>>>> And we came up with a solution we consider the best possible. >>>>>>>>>>>>> If >>>>>>>>>>>>> you >>>>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>>>> solution, >>>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>>>> issues. >>>>>>>>>>>>> >>>>>>>>>>>>> @David >>>>>>>>>>>>>> >>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>>>> term >>>>>>>>>>>>>> and >>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>> >>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>>>> ARM and >>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, >>>>>>>>>>>>> I >>>>>>>>>>>>> used 'read' >>>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method >>>>>>>>>>>>> name >>>>>>>>>>>>> above). >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>>> processors >>>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>>> >>>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> a few >>>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>> taskqueue >>>>>>>>>>>>>> problem yet, >>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>> continuous. >>>>>>>>>>>>> >>>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is >>>>>>>>>>>>>>> so >>>>>>>>>>>>>>> different?) >>>>>>>>>>>>>> >>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. >>>>>>>>>>>>>> Therefore >>>>>>>>>>>>>> I contributed a >>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but >>>>>>>>>>>>>> not >>>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods >>>>>>>>>>>>>> that >>>>>>>>>>>>>> are evaluated >>>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>>> problem >>>>>>>>>>>>>> is that >>>>>>>>>>>>>> store >>>>>>>>>>>>>> sync >>>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>>> only >>>>>>>>>>>>>> sync >>>>>>>>>>>>>> load >>>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>>> pass that test. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>>> term and >>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>>> >>>>>>>>>>>>>> store >>>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler >>>>>>>>>>>>>> instructions >>>>>>>>>>>>>> that >>>>>>>>>>>>>> do what is required. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by >>>>>>>>>>>>>>>> JMM >>>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>>> initializing >>>>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>>> volatiles do >>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the >>>>>>>>>>>>>> JMM >>>>>>>>>>>>>> that >>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>>>> Aleksey >>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due >>>>>>>>>>>>>> to a >>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. >>>>>>>>>>>>>>> We >>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>>>> account >>>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>>> An example: >>>>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore >>>>>>>>>>>>>>> barrier >>>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC >>>>>>>>>>>>>>> operations >>>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> read >>>>>>>>>>>>>>> is inefficient on platforms that have >>>>>>>>>>>>>>> multiple-read-atomicity. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail >>>>>>>>>>>>>> with a >>>>>>>>>>>>>> few >>>>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>>>> will >>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is >>>>>>>>>>>>>> so >>>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>>> moment. The >>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>>> requirements for >>>>>>>>>>>>>> volatile accesses is if there are global visibility issues >>>>>>>>>>>>>> that >>>>>>>>>>>>>> are not >>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>>>> store >>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds >>>>>>>>>>>>>> me >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>>>> software >>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>>>> don't have >>>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of >>>>>>>>>>>>>> days >>>>>>>>>>>>>> I will >>>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, >>>>>>>>>>>>>>> so >>>>>>>>>>>>>>> it might >>>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>>>> them). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>>> I agree we should not change it in the ppc port. If you >>>>>>>>>>>>>>> wish, I >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a >>>>>>>>>>>>>>> reasonable >>>>>>>>>>>>>>> way :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From what I understand what we see here is an >>>>>>>>>>>>>>> attempt to >>>>>>>>>>>>>>> fix an >>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to >>>>>>>>>>>>>>> make >>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>>>> doing the >>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>>> performance >>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I >>>>>>>>>>>>>>> said >>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed >>>>>>>>>>>>>>> using >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>>> properties >>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not >>>>>>>>>>>>>>> needed >>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess >>>>>>>>>>>>>>> should >>>>>>>>>>>>>>> reduce >>>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not >>>>>>>>>>>>>>> needed >>>>>>>>>>>>>>> under >>>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change >>>>>>>>>>>>>>>> our >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() >>>>>>>>>>>>>>>> now). >>>>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>>> like this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the >>>>>>>>>>>>>>> JMM >>>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From what I understand our ppc port is also >>>>>>>>>>>>>>>> affected. >>>>>>>>>>>>>>>> David? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use >>>>>>>>>>>>>>>> fat membar >>>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>>> // Add MemBarRelease for constructors >>>>>>>>>>>>>>>> which write >>>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>>> __________ __________ __________ >>>>>>>>>>>>>>>>> __________ >>>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) >>>>>>>>>>>>>>>>> read(y) >>>>>>>>>>>>>>>>> read(y) >>>>>>>>>>>>>>>>> read(x) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. >>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Further this change contains a fix that assures that >>>>>>>>>>>>>>>>> volatile >>>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>>> written in constructors are visible before the reference >>>>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8031581_aix_addons_and_fixes Type: application/octet-stream Size: 33250 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140122/a8857132/8031581_aix_addons_and_fixes-0001.obj From vladimir.kozlov at oracle.com Wed Jan 22 13:41:03 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 22 Jan 2014 21:41:03 +0000 Subject: hg: ppc-aix-port/stage-9/jdk: 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Message-ID: <20140122214158.2486562681@hg.openjdk.java.net> Changeset: 902aa2b3265c Author: simonis Date: 2014-01-20 17:16 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/902aa2b3265c 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Reviewed-by: alanb, sla ! make/CompileJavaClasses.gmk + src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/aix/native/java/net/aix_close.c ! src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/management/DiagnosticCommandImpl.c ! src/share/transport/socket/socketTransport.c ! src/solaris/classes/java/lang/UNIXProcess.java.aix ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/management/OperatingSystemImpl.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/Net.c From vladimir.kozlov at oracle.com Wed Jan 22 15:53:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 15:53:03 -0800 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 Message-ID: <52E059DF.50600@oracle.com> I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 to latest ppc64 sources: http://hg.openjdk.java.net/ppc-aix-port/stage-9 I have build failure on Mac OS X (on other platforms it passed). See the output below. I tried different JPRT queues - the same problem. During sync I had to merge common/autoconf/toolchain.m4 (merged automatically) and regenerate generated-configure.sh. The latest changes to toolchain.m4 was: http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 Next jdk files merge was resolved automatically: merging make/CompileDemos.gmk merging src/solaris/bin/java_md_solinux.c merging test/ProblemList.txt merging test/tools/launcher/ExecutionEnvironment.java 291 files updated, 4 files merged, 14 files removed, 0 files unresolved Thanks, Vladimir The build failure on Mac OS X: Cleaning up: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Outputting classes to: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Searching for bridged frameworks in: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge found 3 frameworks Parsing XML Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at com.apple.jobjc.Coder.(Coder.java:60) at com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) at com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) at com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) at com.apple.internal.jobjc.generator.model.Element.(Element.java:47) at com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) at com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) at com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) make[2]: *** [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] Error 1 make[1]: *** [gensrc-only] Error 2 make: *** [jdk-only] Error 2 From henry.jen at oracle.com Wed Jan 22 16:18:22 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 22 Jan 2014 16:18:22 -0800 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E059DF.50600@oracle.com> References: <52E059DF.50600@oracle.com> Message-ID: <52E05FCE.1040901@oracle.com> I haven't tried this, but Tim Bell mentioned this in an email inquiry I had earlier, > This will be cured when the fix for 8021266 is pushed to JDK 9 (see > attached). > > In the meantime, the workaround in JPRT is to submit your JDK 9 jobs > with '-bootproduct jdk7u7' since the 7u51 release can not serve as a > boot JDK. Cheers, Henry On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: > I need help. > > I am trying to do control build in JPRT after I merged latest jdk9 source: > > http://hg.openjdk.java.net/jdk9/jdk9 > > to latest ppc64 sources: > > http://hg.openjdk.java.net/ppc-aix-port/stage-9 > > I have build failure on Mac OS X (on other platforms it passed). See the > output below. I tried different JPRT queues - the same problem. > > During sync I had to merge common/autoconf/toolchain.m4 (merged > automatically) and regenerate generated-configure.sh. > > The latest changes to toolchain.m4 was: > > http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 > > Next jdk files merge was resolved automatically: > > merging make/CompileDemos.gmk > merging src/solaris/bin/java_md_solinux.c > merging test/ProblemList.txt > merging test/tools/launcher/ExecutionEnvironment.java > 291 files updated, 4 files merged, 14 files removed, 0 files unresolved > > Thanks, > Vladimir > > The build failure on Mac OS X: > > Cleaning up: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > > Outputting classes to: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > > Searching for bridged frameworks in: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge > > found 3 frameworks > Parsing XML > Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in > java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at com.apple.jobjc.Coder.(Coder.java:60) > at > com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) > > at > com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) > > at > com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) > at > com.apple.internal.jobjc.generator.model.Element.(Element.java:47) > at > com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) > > at > com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) > > at > com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) > make[2]: *** > [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] > Error 1 > make[1]: *** [gensrc-only] Error 2 > make: *** [jdk-only] Error 2 From vladimir.kozlov at oracle.com Wed Jan 22 16:52:52 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 00:52:52 +0000 Subject: hg: ppc-aix-port/stage/jdk: 4 new changesets Message-ID: <20140123005354.F2F166269E@hg.openjdk.java.net> Changeset: 07beb32265e9 Author: simonis Date: 2014-01-17 21:54 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/07beb32265e9 8028537: PPC64: Updated the JDK regression tests to run on AIX Reviewed-by: alanb Contributed-by: luchsh at linux.vnet.ibm.com, spoole at linux.vnet.ibm.com, volker.simonis at gmail.com ! test/ProblemList.txt ! test/com/sun/corba/5036554/TestCorbaBug.sh ! test/com/sun/corba/cachedSocket/7056731.sh ! test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/ShellScaffold.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/Send12k.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/SBC.java ! test/java/nio/file/Files/walkFileTree/find.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatTest.sh ! test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatThreadTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/script/CommonSetup.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh ! test/sun/net/ftp/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/rmi/rmic/newrmic/equivalence/batch.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/KeyStore/DKSTest.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/StorePasswordsByShell.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/tools/common/CommonSetup.sh ! test/sun/tools/jconsole/ResourceCheckTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/Settings.java ! test/tools/launcher/TestHelper.java Changeset: 3830849a1ba4 Author: simonis Date: 2014-01-20 09:20 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/3830849a1ba4 8031134: PPC64: implement printing on AIX Reviewed-by: prr ! src/solaris/classes/sun/print/UnixPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: a6902238682c Author: simonis Date: 2014-01-20 09:24 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/a6902238682c 8031997: PPC64: Make the various POLL constants system dependant Reviewed-by: alanb ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! src/aix/classes/sun/nio/ch/AixPollPort.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java ! src/windows/classes/sun/nio/ch/SinkChannelImpl.java ! src/windows/classes/sun/nio/ch/SourceChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c ! src/windows/native/sun/nio/ch/nio_util.h Changeset: c44d84c6774d Author: simonis Date: 2014-01-20 17:16 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/c44d84c6774d 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Reviewed-by: alanb, sla ! make/CompileJavaClasses.gmk + src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/aix/native/java/net/aix_close.c ! src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/management/DiagnosticCommandImpl.c ! src/share/transport/socket/socketTransport.c ! src/solaris/classes/java/lang/UNIXProcess.java.aix ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/management/OperatingSystemImpl.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/Net.c From vladimir.kozlov at oracle.com Wed Jan 22 17:17:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 17:17:51 -0800 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E05FCE.1040901@oracle.com> References: <52E059DF.50600@oracle.com> <52E05FCE.1040901@oracle.com> Message-ID: <52E06DBF.2020000@oracle.com> Thank you very much, Henry The suggested workaround helped! Thanks, Vladimir On 1/22/14 4:18 PM, Henry Jen wrote: > I haven't tried this, but Tim Bell mentioned this in an email inquiry I > had earlier, > >> This will be cured when the fix for 8021266 is pushed to JDK 9 (see >> attached). >> >> In the meantime, the workaround in JPRT is to submit your JDK 9 jobs >> with '-bootproduct jdk7u7' since the 7u51 release can not serve as a >> boot JDK. > > Cheers, > Henry > > > On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: >> I need help. >> >> I am trying to do control build in JPRT after I merged latest jdk9 >> source: >> >> http://hg.openjdk.java.net/jdk9/jdk9 >> >> to latest ppc64 sources: >> >> http://hg.openjdk.java.net/ppc-aix-port/stage-9 >> >> I have build failure on Mac OS X (on other platforms it passed). See the >> output below. I tried different JPRT queues - the same problem. >> >> During sync I had to merge common/autoconf/toolchain.m4 (merged >> automatically) and regenerate generated-configure.sh. >> >> The latest changes to toolchain.m4 was: >> >> http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 >> >> Next jdk files merge was resolved automatically: >> >> merging make/CompileDemos.gmk >> merging src/solaris/bin/java_md_solinux.c >> merging test/ProblemList.txt >> merging test/tools/launcher/ExecutionEnvironment.java >> 291 files updated, 4 files merged, 14 files removed, 0 files unresolved >> >> Thanks, >> Vladimir >> >> The build failure on Mac OS X: >> >> Cleaning up: >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> >> Outputting classes to: >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> >> Searching for bridged frameworks in: >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge >> >> >> found 3 frameworks >> Parsing XML >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in >> java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at com.apple.jobjc.Coder.(Coder.java:60) >> at >> com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) >> >> >> at >> com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) >> >> >> at >> com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) >> >> at >> com.apple.internal.jobjc.generator.model.Element.(Element.java:47) >> at >> com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) >> >> >> at >> com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) >> >> >> at >> com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) >> make[2]: *** >> [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] >> >> Error 1 >> make[1]: *** [gensrc-only] Error 2 >> make: *** [jdk-only] Error 2 From vladimir.kozlov at oracle.com Wed Jan 22 12:57:03 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 22 Jan 2014 20:57:03 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Message-ID: <20140122205707.AB3676267B@hg.openjdk.java.net> Changeset: 3514ee402842 Author: goetz Date: 2014-01-16 14:25 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/3514ee402842 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Reviewed-by: dholmes, kvn Contributed-by: martin.doerr at sap.com ! src/cpu/ppc/vm/globalDefinitions_ppc.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/utilities/globalDefinitions.hpp From vladimir.kozlov at oracle.com Wed Jan 22 18:25:43 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:25:43 +0000 Subject: hg: ppc-aix-port/stage-9/jaxp: 5 new changesets Message-ID: <20140123022559.2B6EC626A4@hg.openjdk.java.net> Changeset: 9df31dae3649 Author: joehw Date: 2013-12-23 13:57 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/9df31dae3649 8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars Reviewed-by: dfuchs, lancea, ulfzibis ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: e3b116f1f444 Author: joehw Date: 2013-12-23 14:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/e3b116f1f444 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013 Reviewed-by: lancea, mchung ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java ! src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java ! src/com/sun/xml/internal/stream/Entity.java ! src/com/sun/xml/internal/stream/StaxXMLInputSource.java ! src/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/com/sun/xml/internal/stream/writers/WriterUtility.java ! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/javax/xml/XMLConstants.java ! src/javax/xml/parsers/SAXParser.java ! src/javax/xml/validation/Validator.java ! src/javax/xml/xpath/XPathException.java ! src/javax/xml/xpath/XPathFactory.java ! src/org/xml/sax/helpers/NewInstance.java ! src/org/xml/sax/helpers/ParserAdapter.java ! src/org/xml/sax/helpers/ParserFactory.java ! src/org/xml/sax/helpers/SecuritySupport.java ! src/org/xml/sax/helpers/XMLReaderFactory.java Changeset: 6cfe9502343e Author: joehw Date: 2014-01-05 21:00 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/6cfe9502343e 8027359: XML parser returns incorrect parsing results Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: e5256f530a9b Author: joehw Date: 2013-12-12 11:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/e5256f530a9b 8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification Reviewed-by: alanb, dfuchs, lancea ! src/javax/xml/stream/XMLOutputFactory.java Changeset: 5be9a92100bf Author: katleman Date: 2014-01-21 18:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxp/rev/5be9a92100bf Added tag jdk9-b01 for changeset e5256f530a9b ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 18:25:36 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:25:36 +0000 Subject: hg: ppc-aix-port/stage-9/corba: 2 new changesets Message-ID: <20140123022539.3C6DA626A3@hg.openjdk.java.net> Changeset: 79a8136b18c1 Author: ssides Date: 2013-12-23 18:42 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/corba/rev/79a8136b18c1 8029231: Update copyright years for files in corba repository for 2013 Reviewed-by: mchung, coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java Changeset: 95f1e7d56136 Author: katleman Date: 2014-01-21 18:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/corba/rev/95f1e7d56136 Added tag jdk9-b01 for changeset 79a8136b18c1 ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 18:26:05 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:26:05 +0000 Subject: hg: ppc-aix-port/stage-9/jaxws: Added tag jdk9-b01 for changeset 9c9fabbcd3d5 Message-ID: <20140123022612.A6CE9626A5@hg.openjdk.java.net> Changeset: 94c4578b2876 Author: katleman Date: 2014-01-21 18:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jaxws/rev/94c4578b2876 Added tag jdk9-b01 for changeset 9c9fabbcd3d5 ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 18:27:54 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:27:54 +0000 Subject: hg: ppc-aix-port/stage-9/nashorn: Added tag jdk9-b01 for changeset 65347535840f Message-ID: <20140123022757.57CC4626A7@hg.openjdk.java.net> Changeset: 3f1385a3bbf5 Author: katleman Date: 2014-01-21 18:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/nashorn/rev/3f1385a3bbf5 Added tag jdk9-b01 for changeset 65347535840f ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 18:26:23 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:26:23 +0000 Subject: hg: ppc-aix-port/stage-9/langtools: 25 new changesets Message-ID: <20140123022748.9450F626A6@hg.openjdk.java.net> Changeset: 0a2edd52d017 Author: vromero Date: 2013-12-16 14:32 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/0a2edd52d017 8020216: javac, compile time error isn't shown when final static field is not assigned Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/flow/T8020216/CompileTimeErrorForNonAssignedStaticFieldTest.java + test/tools/javac/flow/T8020216/CompileTimeErrorForNonAssignedStaticFieldTest.out Changeset: cd3f9e77eca4 Author: vromero Date: 2013-12-16 15:07 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/cd3f9e77eca4 8028708: TEST_BUG, Tests should pass through VM options, langtools tests Reviewed-by: jjg, vromero Contributed-by: andrey.x.nazarov at oracle.com ! test/tools/javac/api/ToolProvider/HelloWorldTest.java ! test/tools/javac/api/ToolProvider/ToolProviderTest1.java ! test/tools/javac/api/ToolProvider/ToolProviderTest2.java ! test/tools/javac/lib/ToolBox.java Changeset: 27f2ac8ee5b5 Author: vromero Date: 2013-12-16 17:33 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/27f2ac8ee5b5 8030214: fix for JDK-8020216 breaks the build Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java - test/tools/javac/flow/T8020216/CompileTimeErrorForNonAssignedStaticFieldTest.java - test/tools/javac/flow/T8020216/CompileTimeErrorForNonAssignedStaticFieldTest.out Changeset: f52909109e6d Author: darcy Date: 2013-12-16 10:15 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/f52909109e6d 8028545: Add -source 9 and -target 9 to javac 8000961: Change javac source and target default to 9 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Profile.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/profiles/ProfileOptionTest.java ! test/tools/javac/versions/check.sh Changeset: e59a993abd88 Author: jlahoda Date: 2013-12-17 10:55 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/e59a993abd88 8029715: test needs bugID added to @bug tag Summary: Adding forgotten bug number Reviewed-by: vromero ! test/tools/javac/processing/model/type/IntersectionPropertiesTest.java Changeset: bc18278c195e Author: jlahoda Date: 2013-12-17 10:55 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/bc18278c195e 8029800: Flags.java uses String.toLowerCase without specifying Locale Summary: Introducing StringUtils.toLowerCase/toUpperCase independent on the default locale, converting almost all usages of String.toLowerCase/toUpperCase to use the new methods. Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclint/Checker.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/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + src/share/classes/com/sun/tools/javac/util/StringUtils.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + test/tools/javac/NoStringToLower.java + test/tools/javac/util/StringUtilsTest.java Changeset: 55e4fd84b317 Author: jlahoda Date: 2013-12-17 10:58 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/55e4fd84b317 8028415: TreeMaker.Literal(Object) creates invalid JCLiterals when passed a Character. Summary: JCLiteral for char must contain an Integer, not the provided Character. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! test/tools/javac/tree/MakeLiteralTest.java Changeset: 378aa10645e1 Author: jlahoda Date: 2013-12-17 10:58 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/378aa10645e1 8028235: Better error recovery for parsing 'void' as a type of the lambda parameter Summary: Handle "void" as a primitive type in JavacParser.analyzeParens. Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/lambda/VoidLambdaParameter.java + test/tools/javac/lambda/VoidLambdaParameter.out ! test/tools/javac/parser/JavacParserTest.java Changeset: 744e0f74f7a0 Author: darcy Date: 2013-12-17 10:28 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/744e0f74f7a0 8030080: Correct misstatement in JSR 269 MR (in javax.lang.model) Reviewed-by: jfranck ! src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: 9493a72cf1f5 Author: emc Date: 2013-12-17 18:15 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/9493a72cf1f5 8030642: Add golden files to javac/limits Summary: Add golden files to check output of negative compilation tests in javac/limits Reviewed-by: jjg, emc Contributed-by: paul.govereau at oracle.com ! test/tools/javac/limits/ArrayDims2.java ! test/tools/javac/limits/ArrayDims4.java ! test/tools/javac/limits/ArrayDims5.java ! test/tools/javac/limits/CodeSize.java ! test/tools/javac/limits/LongName.java ! test/tools/javac/limits/PoolSize1.java ! test/tools/javac/limits/PoolSize2.java ! test/tools/javac/limits/StringLength.java Changeset: c34aa8829e0a Author: emc Date: 2013-12-17 19:27 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/c34aa8829e0a 8030687: Add .out files to fix failing tests Summary: Forgot to hg add golden files in a previous fix Reviewed-by: jjg + test/tools/javac/limits/ArrayDims2.out + test/tools/javac/limits/ArrayDims4.out + test/tools/javac/limits/ArrayDims5.out + test/tools/javac/limits/CodeSize.out + test/tools/javac/limits/LongName.out + test/tools/javac/limits/PoolSize1.out + test/tools/javac/limits/PoolSize2.out + test/tools/javac/limits/StringLength.out Changeset: be07a9f8f5f0 Author: briangoetz Date: 2013-12-18 10:29 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/be07a9f8f5f0 8030253: Update langtools to use strings-in-switch 8030262: Update langtools to use foreach loops 8030245: Update langtools to use try-with-resources and multi-catch Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexCache.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/sjavac/Log.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/javax/lang/model/SourceVersion.java Changeset: aebf9484a765 Author: ksrini Date: 2013-12-06 09:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/aebf9484a765 8029504: Regression: TestDocRootLink test fails on Windows Reviewed-by: bpatel, jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java Changeset: 5147975ac108 Author: vromero Date: 2013-12-18 19:15 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/5147975ac108 8029569: internal javac cast exception when resolving varargs ambiguity Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8029569/VarargsAmbiguityCrashTest.java + test/tools/javac/T8029569/VarargsAmbiguityCrashTest.out Changeset: 6015aabfbe6b Author: vromero Date: 2013-12-18 19:22 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/6015aabfbe6b 8029721: javac crash for annotated parameter type of lambda in a field Reviewed-by: rfield, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/lambda/LambdaScope05.out Changeset: b9bf5b3d5445 Author: briangoetz Date: 2013-12-18 16:05 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/b9bf5b3d5445 8030244: Update langtools to use Diamond Reviewed-by: darcy ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/classfile/ReferenceFinder.java ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Type.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PropertyBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.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/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.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/api/MultiTaskListener.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/CompileStates.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexCache.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.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/JNIWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/jvm/Profile.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! 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/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/LazyDocCommentTable.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/Context.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java ! src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/CleanProperties.java ! src/share/classes/com/sun/tools/sjavac/CompileChunk.java ! src/share/classes/com/sun/tools/sjavac/CompileProperties.java ! src/share/classes/com/sun/tools/sjavac/CopyFile.java ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/Module.java ! src/share/classes/com/sun/tools/sjavac/Package.java ! src/share/classes/com/sun/tools/sjavac/Source.java ! src/share/classes/com/sun/tools/sjavac/Util.java ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java ! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/share/classes/javax/lang/model/SourceVersion.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/tools/DiagnosticCollector.java ! src/share/classes/javax/tools/JavaFileObject.java ! src/share/classes/javax/tools/StandardLocation.java ! src/share/classes/javax/tools/ToolProvider.java Changeset: c0ebdd10888c Author: emc Date: 2013-12-19 11:38 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/c0ebdd10888c 8030726: tools/javac/NoStringToLower.java fails due to enforcement no use of String.toLowerCase on non-langtools classes Summary: Fix NoStringToLower test to only enforce ban on String.toLowerCase on langtools classes Reviewed-by: vromero, jfranck Contributed-by: paul.govereau at oracle.com ! test/tools/javac/NoStringToLower.java Changeset: a10c5a27b7be Author: vromero Date: 2013-12-19 20:16 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/a10c5a27b7be 8030807: langtools should still build using jdk 7 Reviewed-by: briangoetz ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/javax/tools/DiagnosticCollector.java ! src/share/classes/javax/tools/ToolProvider.java Changeset: 8af87c6ebafc Author: vromero Date: 2013-12-19 21:58 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/8af87c6ebafc 8030218: javac, compile time error isn't shown when final static field is not assigned, follow-up Reviewed-by: jjg, jfranck, sundar ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/flow/T8030218/CompileTimeErrorForNonAssignedStaticFieldTest.java + test/tools/javac/flow/T8030218/CompileTimeErrorForNonAssignedStaticFieldTest.out Changeset: 41773f3d520b Author: vromero Date: 2013-12-19 22:24 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/41773f3d520b 8029240: Default methods not always visible under -source 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8029240/DefaultMethodsNotVisibileForSource7Test.java ! test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 6503222744ea Author: rfield Date: 2013-12-22 21:57 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/6503222744ea 8030626: java.lang.VerifyError: Bad return type when lambda's body is in parentheses Summary: properly type convert the body of a lambda expression (forward port to JDK9 of 8029558) Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/LambdaParenGeneric.java + test/tools/javac/lambda/LambdaParenGenericOrig.java Changeset: 0d0ca880c22e Author: darcy Date: 2014-01-07 11:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/0d0ca880c22e 8028543: Add SourceVersion.RELEASE_9 Reviewed-by: jjg ! src/share/classes/javax/lang/model/SourceVersion.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/processing/model/TestSourceVersion.java Changeset: 28e6d4668450 Author: darcy Date: 2014-01-07 13:47 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/28e6d4668450 8031360: Update langtools code base to use RELEASE_9 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! test/tools/javac/lib/JavacTestingAbstractProcessor.java Changeset: 077c12d527fb Author: darcy Date: 2014-01-07 15:00 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/077c12d527fb 8000962: Update JDK_MINOR_VERSION for JDK 9 Reviewed-by: jjg, ksrini ! test/tools/javac/MethodParameters/AnnotationTest.java ! test/tools/javac/MethodParameters/AnonymousClass.java ! test/tools/javac/MethodParameters/CaptureTest.java ! test/tools/javac/MethodParameters/Constructors.java ! test/tools/javac/MethodParameters/EnumTest.java ! test/tools/javac/MethodParameters/InstanceMethods.java ! test/tools/javac/MethodParameters/LambdaTest.java ! test/tools/javac/MethodParameters/LocalClassTest.java ! test/tools/javac/MethodParameters/MemberClassTest.java ! test/tools/javac/MethodParameters/StaticMethods.java ! test/tools/javac/MethodParameters/UncommonParamNames.java Changeset: a90e57a4c87d Author: katleman Date: 2014-01-21 18:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/langtools/rev/a90e57a4c87d Added tag jdk9-b01 for changeset 077c12d527fb ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 18:31:23 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:31:23 +0000 Subject: hg: ppc-aix-port/stage-9/hotspot: 2 new changesets Message-ID: <20140123023129.D593F626AA@hg.openjdk.java.net> Changeset: 239f9b9c86e3 Author: katleman Date: 2014-01-21 18:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/239f9b9c86e3 Added tag jdk9-b01 for changeset 050a626a8895 ! .hgtags Changeset: 12fb826833f0 Author: kvn Date: 2014-01-22 14:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/12fb826833f0 Merge From vladimir.kozlov at oracle.com Wed Jan 22 18:25:31 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:25:31 +0000 Subject: hg: ppc-aix-port/stage-9: 7 new changesets Message-ID: <20140123022532.0A770626A1@hg.openjdk.java.net> Changeset: c3c75eda6606 Author: erikj Date: 2013-12-17 11:09 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/c3c75eda6606 8029797: Let jprt run configure when building Reviewed-by: tbell ! Makefile ! make/Jprt.gmk ! make/Main.gmk ! make/MakeHelpers.gmk ! make/jprt.properties Changeset: bd254db01a0e Author: erikj Date: 2013-12-19 14:11 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/bd254db01a0e 8030793: Update jprt.properties to release jdk9 Reviewed-by: chegar ! make/jprt.properties Changeset: e9dcd2dbb06f Author: darcy Date: 2014-01-03 09:37 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/e9dcd2dbb06f 8031081: Use separate doclint flags for different doc bundles Reviewed-by: chegar, tbell ! make/Javadoc.gmk Changeset: 99544d4803b0 Author: darcy Date: 2014-01-07 10:56 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/99544d4803b0 8000962: Update JDK_MINOR_VERSION for JDK 9 Reviewed-by: katleman, erikj, wetmore ! common/autoconf/version-numbers Changeset: 50669e45cec4 Author: erikj Date: 2014-01-08 14:02 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/50669e45cec4 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb, ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 91b82f8211e4 Author: katleman Date: 2014-01-21 18:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/91b82f8211e4 Added tag jdk9-b01 for changeset 50669e45cec4 ! .hgtags Changeset: 4967c0f260dd Author: kvn Date: 2014-01-22 14:18 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/rev/4967c0f260dd Merge ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From vladimir.kozlov at oracle.com Wed Jan 22 18:34:41 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 02:34:41 +0000 Subject: hg: ppc-aix-port/stage-9/jdk: 89 new changesets Message-ID: <20140123025351.90D0C626AB@hg.openjdk.java.net> Changeset: 5a73e4aee645 Author: darcy Date: 2013-12-13 15:24 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/5a73e4aee645 8030082: Fix raw types lint warnings, etc. in various sun.security libraries Reviewed-by: chegar, mullan ! src/share/classes/sun/security/jca/ProviderConfig.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: f92e3055433c Author: bpb Date: 2013-12-13 16:15 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/f92e3055433c 4891331: BigInteger a.multiply(a) should use squaring code Summary: Change multiply(BigInteger a) to return square() if a == this and the number of ints in the magnitude is over a threshold. Reviewed-by: darcy, shade ! src/share/classes/java/math/BigInteger.java Changeset: 1f351ad06e95 Author: alanb Date: 2013-12-14 09:27 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/1f351ad06e95 8027212: java/nio/channels/Selector/SelectAfterRead.java fails intermittently Reviewed-by: chegar, ewang ! test/java/nio/channels/Selector/ByteServer.java ! test/java/nio/channels/Selector/ReadAfterConnect.java ! test/java/nio/channels/Selector/SelectAfterRead.java ! test/java/nio/channels/Selector/SelectWrite.java Changeset: d8c8b3f38f15 Author: dxu Date: 2013-12-14 16:37 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/d8c8b3f38f15 8022219: Intermittent test failures in java/util/zip/ZipFile Reviewed-by: alanb, chegar ! test/java/util/zip/ZipFile/ReadLongZipFileName.java Changeset: 0fdbd30a9f1c Author: dxu Date: 2013-12-14 20:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/0fdbd30a9f1c 8025437: Check DefaultProxySelector for JNI pending exception issues Reviewed-by: michaelm, chegar, alanb ! src/solaris/native/sun/net/spi/DefaultProxySelector.c Changeset: caa10a9377c9 Author: alanb Date: 2013-12-15 08:11 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/caa10a9377c9 8029805: Remove LogManager addPropertyChangeListener and removePropertyChangeListener methods 8029806: Remove Packer/Unpacker addPropertyChangeLister and removePropertyListener methods Reviewed-by: dfuchs, tbell, mchung, ihse ! make/CreateJars.gmk ! make/Tools.gmk - make/src/classes/build/tools/classfile/RemoveMethods.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/LogManager.java ! test/TEST.groups - test/java/util/logging/Listeners.java - test/java/util/logging/ListenersWithSM.java - test/java/util/logging/java.policy - test/tools/pack200/NoBeans.java - test/tools/pack200/Reflect.java Changeset: 15babe8b90e6 Author: xuelei Date: 2013-12-15 20:24 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/15babe8b90e6 8028562: Test SSLSocketSSLEngineTemplate.java intermittent failed with "Data length error" Summary: test stabilization, read one more time in case of message fragment Reviewed-by: mullan, xuelei Contributed-by: Zaiyao Liu ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 740772b29f39 Author: sla Date: 2013-12-16 10:51 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/740772b29f39 8030036: Updates to ProblemList.txt after same-binaries run Reviewed-by: alanb ! test/ProblemList.txt Changeset: 60ed49f7d7fe Author: sla Date: 2013-12-16 11:04 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/60ed49f7d7fe 8028430: JDI: ReferenceType.visibleMethods() return wrong visible methods Reviewed-by: mchung ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java + test/com/sun/jdi/VisibleMethods.java Changeset: ee5500f3d970 Author: sla Date: 2013-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/ee5500f3d970 4660158: TTY: NumberFormatException while trying to set values by 'set' command Reviewed-by: alanb, sspitsyn ! src/share/classes/com/sun/tools/example/debug/expr/Expr.jj ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java + src/share/classes/com/sun/tools/example/debug/expr/JavaCharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java + test/com/sun/jdi/JdbExprTest.sh Changeset: 341192acab7a Author: sla Date: 2013-12-16 15:38 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/341192acab7a 8030204: com/sun/jdi/JdbExprTest.sh: Required output "Can\\'t convert 2147483648 to int" not found Reviewed-by: alanb ! test/com/sun/jdi/JdbExprTest.sh Changeset: 6a9468263b23 Author: alanb Date: 2013-12-16 15:05 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/6a9468263b23 8029904: Remove com.sun.security.auth.callback.DialogCallbackHandler Reviewed-by: mullan ! make/profile-rtjar-includes.txt - src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java - test/com/sun/security/auth/callback/DialogCallbackHandler/Default.java ! test/com/sun/security/sasl/digest/NoQuoteParams.java ! test/sun/security/pkcs11/Provider/Login.java Changeset: dfe666d39950 Author: alanb Date: 2013-12-16 19:52 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/dfe666d39950 6706208: (cs) CharsetProvider permission check cleanup Reviewed-by: chegar, mchung ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java Changeset: 92c5fbbd8fbd Author: mduigou Date: 2013-12-13 13:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/92c5fbbd8fbd 8030016: HashMap.computeIfAbsent generates spurious access event Reviewed-by: psandoz, bchristi ! src/share/classes/java/util/HashMap.java + test/java/util/LinkedHashMap/ComputeIfAbsentAccessOrder.java ! test/java/util/Map/Defaults.java Changeset: 30d83b6b0932 Author: mduigou Date: 2013-12-13 13:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/30d83b6b0932 8029055: Map.merge implementations should refuse null value param Reviewed-by: briangoetz, dl ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java Changeset: 0eabaeea675c Author: sla Date: 2013-12-17 08:07 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/0eabaeea675c 6605915: jinfo -flag functionality doesn't work with core files Reviewed-by: mchung, jbachorik ! src/share/classes/sun/tools/jinfo/JInfo.java Changeset: d4060ecc471e Author: alanb Date: 2013-12-17 13:27 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/d4060ecc471e 8030035: Create a stable test group in TEST.groups Summary: Added known stable tests into a separate group Reviewed-by: alanb Contributed-by: balchandra.vaidya at oracle.com ! test/TEST.groups Changeset: e0f7ff38be9e Author: mduigou Date: 2013-12-17 09:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e0f7ff38be9e 8029795: LinkedHashMap.getOrDefault() doesn't update access order. Reviewed-by: psandoz ! src/share/classes/java/util/LinkedHashMap.java ! test/java/util/LinkedHashMap/Basic.java Changeset: e87b18bdfe28 Author: darcy Date: 2013-12-17 17:14 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e87b18bdfe28 8030084: Fix lint warnings in sun.security.tools.policytool Reviewed-by: mullan ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: e3ae01498b35 Author: alanb Date: 2013-12-18 08:41 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e3ae01498b35 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission Reviewed-by: mchung, prr, art, mullan ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/MouseInfo.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/applet/AppletSecurity.java - src/share/classes/sun/awt/AWTPermissionFactory.java + src/share/classes/sun/awt/AWTPermissions.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! test/java/lang/SecurityManager/NoAWT.java Changeset: cc29c31a7823 Author: jbachorik Date: 2013-12-18 10:58 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/cc29c31a7823 8029890: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails: Blocked thread has 4 blocked counts. Expected 3 Reviewed-by: sla ! test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java Changeset: 78ad43cbe7e2 Author: jbachorik Date: 2013-12-18 11:00 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/78ad43cbe7e2 8029809: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails intermittently with "Operation not permitted" Reviewed-by: sla ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java Changeset: bc7c24915ee9 Author: vinnie Date: 2013-12-18 12:23 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/bc7c24915ee9 8029788: Certificate validation - java.lang.ClassCastException Reviewed-by: xuelei, mullan, weijun ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: ceafbd631c88 Author: rriggs Date: 2013-12-18 09:56 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/ceafbd631c88 7018010: References to ProxySelector is without link Reviewed-by: lancea, darcy, alanb ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java Changeset: ba17303eef79 Author: ksrini Date: 2013-12-18 10:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/ba17303eef79 8024033: [launcher] remove solaris dual mode support Reviewed-by: darcy, martin ! src/solaris/bin/java_md_solinux.c Changeset: a5a19cfc6464 Author: ksrini Date: 2013-12-18 10:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/a5a19cfc6464 8029388: java.exe consumes argument intended for launched java class Reviewed-by: mchung ! src/windows/bin/java_md.c ! test/tools/launcher/ChangeDataModel.java Changeset: de165a2b88fe Author: ksrini Date: 2013-12-18 11:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/de165a2b88fe 8029513: SwingApplet demo files still found in JDK 8 on Solaris Reviewed-by: tbell ! make/CompileDemos.gmk Changeset: ea5a1f0f7af3 Author: xuelei Date: 2013-12-19 02:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/ea5a1f0f7af3 7093640: Enable client-side TLS 1.2 by default Reviewed-by: weijun, mullan, wetmore ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: e9004951beea Author: msheppar Date: 2013-12-19 11:34 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e9004951beea 7102702: java/net/PortUnreachableException/OneExceptionOnly.java failing Summary: change struct sockaddr_in rmtaddr to SOCKETADDRESS rmtaddr in purgeOutstandingICMP Reviewed-by: alanb, chegar ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! test/ProblemList.txt Changeset: e2bdddb8bedf Author: dl Date: 2013-12-19 10:31 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e2bdddb8bedf 8026155: Enhance ForkJoin pool Reviewed-by: chegar, alanb, ahgross ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: 497e5b67e257 Author: chegar Date: 2013-12-19 10:40 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/497e5b67e257 Merge Changeset: 941823df6655 Author: chegar Date: 2013-12-19 13:08 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/941823df6655 Merge Changeset: 9aaa7653bca5 Author: dfuchs Date: 2013-12-19 14:53 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/9aaa7653bca5 8030192: TESTFAIL: java/util/logging/TestLoggerBundleSync.java failed with NPE Summary: This is a test bug - loggers held in local variables can be arbitrarily gc'ed if that variable is no longer used. The fix makes sure that the loggers won't be arbitrarily gc'ed before the test is complete. Reviewed-by: mchung ! test/java/util/logging/TestLoggerBundleSync.java Changeset: 3231e2b60d7b Author: alanb Date: 2013-12-19 18:13 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/3231e2b60d7b 8022879: TEST_BUG: sun/nio/cs/MalformedSurrogates.java fails intermittently Reviewed-by: martin Contributed-by: yiming.wang at oracle.com ! test/sun/nio/cs/MalformedSurrogates.java Changeset: 03d88a2515da Author: mchung Date: 2013-12-19 13:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/03d88a2515da 8029346: LowMemoryTestConcMarkSweepGC.sh fails intermittently with timeout Reviewed-by: mchung Contributed-by: Tristan Yan ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java - test/java/lang/management/MemoryMXBean/LowMemoryTestConcMarkSweepGC.sh - test/java/lang/management/MemoryMXBean/LowMemoryTestParallelGC.sh - test/java/lang/management/MemoryMXBean/LowMemoryTestSerialGC.sh Changeset: c6ea96f25cdc Author: xuelei Date: 2013-12-19 22:59 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/c6ea96f25cdc 8030842: Intermittent test failure SSLSocketTimeoutNulls.java Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java Changeset: 540ed089efdd Author: alanb Date: 2013-12-20 09:58 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/540ed089efdd 8030690: TEST_BUG java/nio/Buffer/Chars.java fails intermittently Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/Buffer/Chars.java Changeset: a46a076bf830 Author: psandoz Date: 2013-12-20 13:38 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/a46a076bf830 8030851: Update code in java.util to use newer language features Reviewed-by: dfuchs, briangoetz, chegar, alanb, mduigou ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSequentialList.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/ArraysParallelSortHelpers.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/StringTokenizer.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/stream/SortedOps.java Changeset: afe4c5f0a8fb Author: dfuchs Date: 2013-12-20 14:53 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/afe4c5f0a8fb 8030187: TEST_BUG: java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java failing again Summary: Yet another issue with Loggers being gc'ed too early. Reviewed-by: mchung ! test/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java Changeset: 33c3c4c0ebcf Author: darcy Date: 2013-12-20 08:59 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/33c3c4c0ebcf 8023471: Add compatibility note to AnnotatedElement Reviewed-by: smarks, jfranck, abuckley ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: 3555f96c4a3a Author: rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/3555f96c4a3a 8030002: Enhance deserialization using readObject Reviewed-by: sherman, chegar, scolebourne ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java Changeset: 3d9dfe04c40c Author: rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/3d9dfe04c40c 8029909: Clarify equals/hashcode behavior for java.time types Summary: Document the behavior of equals and hashcode in java.time.chrono date types Reviewed-by: sherman, scolebourne ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: b42d9d8d0689 Author: darcy Date: 2013-12-20 14:06 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/b42d9d8d0689 8030785: Missing "since 1.8" javadoc for java.lang.reflect.Method:getParameterCount Reviewed-by: mduigou, mchung ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java Changeset: 728ec3ee2a5d Author: smarks Date: 2013-12-13 18:08 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/728ec3ee2a5d 8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons Reviewed-by: mchung, dmocek ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/resources/rmic.properties Changeset: eaa533e9778a Author: tyan Date: 2013-12-20 15:10 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/eaa533e9778a 7168267: Cleanup of rmi regression tests Reviewed-by: smarks ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/reliability/juicer/ApplicationServer.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java Changeset: d2e156b25d0a Author: dfuchs Date: 2013-12-22 11:20 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/d2e156b25d0a 8030850: Setting .level=FINEST in logging configuration file doesn't work Summary: setLevel(INFO) was called too early on root logger, causing the value found in configuration file to be later ignored. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/RootLogger/RootLevelInConfigFile.java + test/java/util/logging/RootLogger/rootlogger.properties Changeset: 3fdddeb63b58 Author: joehw Date: 2013-12-23 14:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/3fdddeb63b58 8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars Reviewed-by: dfuchs, lancea, ulfzibis + test/javax/xml/jaxp/parsers/8029955/EntityScannerTest.java Changeset: 8ab889b624a4 Author: ksrini Date: 2013-12-23 14:24 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/8ab889b624a4 8029997: [infra] remove Solaris ISA directories and the links Reviewed-by: alanb, tbell ! make/Images.gmk ! test/tools/launcher/ExecutionEnvironment.java Changeset: e39b7b1c61db Author: mullan Date: 2013-12-24 08:40 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/e39b7b1c61db 8030813: Signed applet fails to load when CRLs are stored in an LDAP directory Summary: Skip JNDI application resource lookup to avoid recursive JAR validation Reviewed-by: vinnie, herrick ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java Changeset: 8c8af352ad49 Author: mullan Date: 2013-12-24 08:42 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/8c8af352ad49 Merge Changeset: b8fad77f3814 Author: smarks Date: 2013-12-24 16:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/b8fad77f3814 8007256: RMI testlibrary cleanup: remove JavaVMCallbackHandler Reviewed-by: darcy ! test/java/rmi/testlibrary/JavaVM.java Changeset: 7aa58a1362c8 Author: xuelei Date: 2013-12-24 20:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/7aa58a1362c8 8025415: Test SSLSocketImplThrowsWrongExceptions.java timed out Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java Changeset: 076738bb967d Author: weijun Date: 2013-12-30 11:51 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/076738bb967d 8028780: JDK KRB5 module throws OutOfMemoryError when CCache is corrupt Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/GSSNameImpl.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCCacheConstants.java + test/sun/security/jgss/GssMemoryIssues.java - test/sun/security/krb5/TimeInCCache.java + test/sun/security/krb5/ccache/CorruptedCC.java + test/sun/security/krb5/ccache/TimeInCCache.java Changeset: d0e6d466b7c6 Author: igerasim Date: 2013-12-30 16:34 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/d0e6d466b7c6 8030698: Several GUI labels in jconsole need correction Reviewed-by: sla ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: c0165cb2e9b3 Author: msheppar Date: 2014-01-02 19:23 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/c0165cb2e9b3 8027903: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address Summary: check for pending Exception and clear if invoking ipv6 mcast_set_xxx function during setNetworkInterface call flow. Reviewed-by: alanb, chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c Changeset: 18080cca998a Author: dl Date: 2014-01-03 06:22 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/18080cca998a 8031133: AbstractMap should specify its default implementation using @implSpec Reviewed-by: chegar, alanb ! src/share/classes/java/util/AbstractMap.java Changeset: 2a3f779141f0 Author: chegar Date: 2014-01-03 06:28 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/2a3f779141f0 Merge ! src/share/classes/java/util/AbstractMap.java Changeset: f454245399bf Author: alanb Date: 2014-01-03 15:42 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/f454245399bf 8029018: (bf) Check src/share/native/java/nio/Bits.c for JNI pending exceptions Reviewed-by: chegar ! src/share/native/java/nio/Bits.c Changeset: 83e7a201b62c Author: alanb Date: 2014-01-03 15:59 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/83e7a201b62c 8031113: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Basic.java fails intermittently Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: ddd79d3a427a Author: darcy Date: 2014-01-03 09:49 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/ddd79d3a427a 8031148: Fix doclint issues in javax.xml.crypto.dsig Reviewed-by: chegar, mullan ! src/share/classes/javax/xml/crypto/dsig/CanonicalizationMethod.java ! src/share/classes/javax/xml/crypto/dsig/DigestMethod.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureMethod.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignContext.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/XMLValidateContext.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java Changeset: c4afcffdb511 Author: darcy Date: 2014-01-03 10:38 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/c4afcffdb511 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! test/java/util/stream/TestDoubleSumAverage.java Changeset: 1b9c607049c9 Author: bpb Date: 2014-01-03 14:04 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/1b9c607049c9 8029561: Optimization in Integer to string conversion Summary: Remove FIXME-TODO comments as the suggested change does not improve performance. Reviewed-by: darcy ! src/share/classes/java/lang/Integer.java Changeset: df79231a1e18 Author: tyan Date: 2014-01-03 20:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/df79231a1e18 8030284: intermittent StackOverflow in RMI bench/serial test Reviewed-by: smarks ! test/java/rmi/reliability/benchmark/bench/serial/Main.java Changeset: 1a4ed2bd4556 Author: joehw Date: 2014-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/1a4ed2bd4556 8027359: XML parser returns incorrect parsing results Reviewed-by: lancea + test/javax/xml/jaxp/parsers/8027359/XML11EntityScannerTest.java Changeset: 9af7c1225730 Author: michaelm Date: 2014-01-06 11:00 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/9af7c1225730 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname Reviewed-by: alanb, chegar ! src/share/classes/java/net/URLPermission.java + test/java/net/URLPermission/OpenURL.java ! test/java/net/URLPermission/URLPermissionTest.java Changeset: 7bef51488933 Author: darcy Date: 2014-01-06 11:48 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/7bef51488933 8031201: Fix casting lint issues in java.net Reviewed-by: alanb, chegar ! src/share/classes/java/net/Inet6Address.java Changeset: 5d921714a43a Author: juh Date: 2014-01-06 13:20 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/5d921714a43a 8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward() Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: d8759955a757 Author: rriggs Date: 2013-12-11 16:52 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/d8759955a757 8029551: Add value-type notice to java.time classes Summary: Add warning about identity of value types and reference to ValueBased.html Reviewed-by: briangoetz, smarks, scolebourne ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java Changeset: 8aba209fcc73 Author: darcy Date: 2014-01-06 13:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/8aba209fcc73 8031210: Remove serial warning from java.lang.Enum Reviewed-by: lancea, mduigou ! src/share/classes/java/lang/Enum.java Changeset: 10a7f21e6d51 Author: plevart Date: 2014-01-07 09:54 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/10a7f21e6d51 8030801: SocketHandler(host, port) requires permission ("java.util.logging.LoggingPermission" "control") 8029781: Theoretical data race on java.util.logging.Handler.sealed Summary: Use privileged actions instead of racy boolean field to elevate privilege when constructing logging handlers Reviewed-by: mchung, dfuchs ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java + test/java/util/logging/HandlersConfigTest$Configured.props + test/java/util/logging/HandlersConfigTest$Default.props + test/java/util/logging/HandlersConfigTest.java Changeset: 8eb4585ecca7 Author: psandoz Date: 2014-01-07 11:15 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/8eb4585ecca7 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Reviewed-by: darcy ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Changeset: 39808c21755d Author: psandoz Date: 2014-01-07 11:33 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/39808c21755d 8031306: Incorrect bug id on tests Reviewed-by: chegar ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Changeset: 379e2893b058 Author: chegar Date: 2014-01-07 11:34 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/379e2893b058 8031067: java/util/concurrent/atomic/AtomicUpdaters.java: java.lang.Error: Unexpected reflective access Summary: Ensure that the test is not influenced by the default users policy. Reviewed-by: martin ! test/java/util/concurrent/atomic/AtomicUpdaters.java Changeset: 7b38bd0ca1b1 Author: chegar Date: 2014-01-07 12:59 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/7b38bd0ca1b1 8031142: AbstractCollection and AbstractList should specify their default implementation using @implSpec Reviewed-by: martin, psandoz ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java Changeset: b2d3a512a534 Author: chegar Date: 2014-01-07 13:00 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/b2d3a512a534 Merge Changeset: 19027fae2dc9 Author: darcy Date: 2014-01-07 09:09 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/19027fae2dc9 8027063: SecurityManger.getClassContext returns a raw type Reviewed-by: lancea, alanb, xuelei ! src/share/classes/java/lang/SecurityManager.java Changeset: b54fa34779b6 Author: darcy Date: 2014-01-07 09:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/b54fa34779b6 8031302: Fix raw types lint warnings in java.security Reviewed-by: xuelei ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/UnresolvedPermission.java Changeset: 7bb2401e06f9 Author: rriggs Date: 2014-01-07 11:50 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/7bb2401e06f9 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Summary: Correct specification for Duration.toDays, toHours Reviewed-by: lancea, alanb ! src/share/classes/java/time/Duration.java Changeset: 2647b91dbc2a Author: darcy Date: 2014-01-07 09:58 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/2647b91dbc2a 8031326: Use Class rather than Class in java.net method signatures Reviewed-by: alanb, chegar ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java Changeset: 5912c8deb51d Author: darcy Date: 2014-01-07 12:56 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/5912c8deb51d 8031361: Fix raw types warning in java.lang.management Reviewed-by: psandoz, lancea, alanb ! src/share/classes/java/lang/management/ManagementFactory.java Changeset: f1066af06fa0 Author: ascarpino Date: 2014-01-07 14:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/f1066af06fa0 8030823: Security Providers need to have their version numbers updated for JDK9 Reviewed-by: xuelei, wetmore ! src/macosx/classes/apple/security/AppleProvider.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/security/sasl/Provider.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/jgss/SunProvider.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/rsa/SunRsaSign.java ! src/share/classes/sun/security/smartcardio/SunPCSC.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/java/security/Provider/ProviderVersionCheck.java Changeset: 0b15f2e463da Author: darcy Date: 2014-01-07 15:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/0b15f2e463da 8000962: Update JDK_MINOR_VERSION for JDK 9 Reviewed-by: jjg, ksrini ! test/ProblemList.txt Changeset: 9d29ba8fd305 Author: darcy Date: 2014-01-07 19:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/9d29ba8fd305 8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} Reviewed-by: mduigou, lancea ! src/share/classes/sun/misc/Cache.java ! src/share/classes/sun/misc/SoftCache.java Changeset: 2d01f25b1b37 Author: alanb Date: 2014-01-08 12:59 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/2d01f25b1b37 8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds Reviewed-by: alanb Contributed-by: tristan.yan at oracle.com ! test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 1e0ed6b05df7 Author: alanb Date: 2014-01-08 13:08 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/1e0ed6b05df7 6772009: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' Reviewed-by: martin, dholmes Contributed-by: srikalyan.chandrashekar at oracle.com ! test/ProblemList.txt ! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java Changeset: 03b9bcc42484 Author: erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/03b9bcc42484 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java Changeset: 3b4ac8d1b76f Author: dxu Date: 2014-01-08 13:25 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/3b4ac8d1b76f 8028726: (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions Reviewed-by: lancea, chegar, alanb ! src/solaris/native/java/util/FileSystemPreferences.c Changeset: d94b9f4a50e5 Author: katleman Date: 2014-01-21 18:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/d94b9f4a50e5 Added tag jdk9-b01 for changeset 3b4ac8d1b76f ! .hgtags Changeset: f86763a9c959 Author: kvn Date: 2014-01-22 14:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/jdk/rev/f86763a9c959 Merge ! make/CompileDemos.gmk - make/src/classes/build/tools/classfile/RemoveMethods.java - src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java - src/share/classes/sun/awt/AWTPermissionFactory.java ! src/solaris/bin/java_md_solinux.c ! test/ProblemList.txt - test/com/sun/security/auth/callback/DialogCallbackHandler/Default.java - test/java/lang/management/MemoryMXBean/LowMemoryTestConcMarkSweepGC.sh - test/java/lang/management/MemoryMXBean/LowMemoryTestParallelGC.sh - test/java/lang/management/MemoryMXBean/LowMemoryTestSerialGC.sh - test/java/util/logging/Listeners.java - test/java/util/logging/ListenersWithSM.java - test/java/util/logging/java.policy - test/sun/security/krb5/TimeInCCache.java - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java ! test/tools/launcher/ExecutionEnvironment.java - test/tools/pack200/NoBeans.java - test/tools/pack200/Reflect.java From vladimir.kozlov at oracle.com Wed Jan 22 19:53:59 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 03:53:59 +0000 Subject: hg: ppc-aix-port/stage: 4 new changesets Message-ID: <20140123035359.5D9B3626AC@hg.openjdk.java.net> Changeset: ff1478785e43 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/ff1478785e43 Added tag jdk8-b122 for changeset 347009c58816 ! .hgtags Changeset: c330fa67c4da Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/c330fa67c4da Added tag jdk8-b123 for changeset ff1478785e43 ! .hgtags Changeset: 7b40630d3b4b Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/7b40630d3b4b Added tag jdk8u20-b00 for changeset c330fa67c4da ! .hgtags Changeset: fd291afd8ee4 Author: kvn Date: 2014-01-22 17:41 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/fd291afd8ee4 Merge From vladimir.kozlov at oracle.com Wed Jan 22 19:54:02 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 03:54:02 +0000 Subject: hg: ppc-aix-port/stage/corba: 7 new changesets Message-ID: <20140123035406.6F625626AD@hg.openjdk.java.net> Changeset: eb5d3f8ca0ca Author: mfang Date: 2013-12-17 22:03 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/eb5d3f8ca0ca 8026741: jdk8 l10n resource file translation update 5 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp Changeset: 2a8fa4da6ad3 Author: lana Date: 2013-12-23 14:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/2a8fa4da6ad3 Merge Changeset: 5ca1b4c282b8 Author: ssides Date: 2013-12-23 18:42 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/5ca1b4c282b8 8029231: Update copyright years for files in corba repository for 2013 Reviewed-by: mchung, coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java Changeset: 0cd687347540 Author: lana Date: 2013-12-25 10:30 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/0cd687347540 Merge Changeset: 1ecd4619f60c Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/1ecd4619f60c Added tag jdk8-b122 for changeset 0cd687347540 ! .hgtags Changeset: afecd2878aee Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/afecd2878aee Added tag jdk8-b123 for changeset 1ecd4619f60c ! .hgtags Changeset: b4bdf525a374 Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/b4bdf525a374 Added tag jdk8u20-b00 for changeset afecd2878aee ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 19:54:34 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 03:54:34 +0000 Subject: hg: ppc-aix-port/stage/jaxws: 3 new changesets Message-ID: <20140123035443.71771626AF@hg.openjdk.java.net> Changeset: 91f5c542ccad Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxws/rev/91f5c542ccad Added tag jdk8-b122 for changeset bc622ba563f9 ! .hgtags Changeset: 241e4effed6d Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxws/rev/241e4effed6d Added tag jdk8-b123 for changeset 91f5c542ccad ! .hgtags Changeset: b4a4ab8308f6 Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxws/rev/b4a4ab8308f6 Added tag jdk8u20-b00 for changeset 241e4effed6d ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 19:54:50 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 03:54:50 +0000 Subject: hg: ppc-aix-port/stage/langtools: 14 new changesets Message-ID: <20140123035534.E83B1626B0@hg.openjdk.java.net> Changeset: 2d0a0ae7fa9c Author: ksrini Date: 2013-12-06 09:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/2d0a0ae7fa9c 8029504: Regression: TestDocRootLink test fails on Windows Reviewed-by: bpatel, jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java Changeset: 5bf0af735c61 Author: vromero Date: 2013-12-09 19:29 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/5bf0af735c61 8029569: internal javac cast exception when resolving varargs ambiguity Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8029569/VarargsAmbiguityCrashTest.java + test/tools/javac/T8029569/VarargsAmbiguityCrashTest.out Changeset: 847cc0cccfa1 Author: rfield Date: 2013-12-11 11:56 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/847cc0cccfa1 8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses Summary: properly type convert the body of a lambda expression Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/LambdaParenGeneric.java + test/tools/javac/lambda/LambdaParenGenericOrig.java Changeset: d80c3d6f4f05 Author: lana Date: 2013-12-12 19:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/d80c3d6f4f05 Merge Changeset: 8832b6048e65 Author: vromero Date: 2013-12-13 14:13 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/8832b6048e65 8029721: javac crash for annotated parameter type of lambda in a field Reviewed-by: rfield, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/lambda/LambdaScope05.out Changeset: 6d1f9d1fd585 Author: darcy Date: 2013-12-17 10:26 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/6d1f9d1fd585 8030080: Correct misstatement in JSR 269 MR (in javax.lang.model) Reviewed-by: jfranck ! src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: f1be939b49f6 Author: mfang Date: 2013-12-17 23:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/f1be939b49f6 8026741: jdk8 l10n resource file translation update 5 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties Changeset: b8ebde062692 Author: bpatel Date: 2013-12-18 19:48 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/b8ebde062692 8016549: jdk7 javadocs are hard to read Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java ! test/tools/javadoc/api/basic/APITest.java Changeset: 56943b19c119 Author: lana Date: 2013-12-23 14:46 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/56943b19c119 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif Changeset: 998b10c43157 Author: ksrini Date: 2013-12-24 09:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/998b10c43157 8029230: Update copyright year to match last edit in jdk8 langtools repository for 2013 Reviewed-by: ksrini Contributed-by: steve.sides at oracle.com ! make/Makefile ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/sjavac/CleanProperties.java ! src/share/classes/com/sun/tools/sjavac/CompileChunk.java ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java ! src/share/classes/com/sun/tools/sjavac/CompileProperties.java ! src/share/classes/com/sun/tools/sjavac/CopyFile.java ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Log.java ! src/share/classes/com/sun/tools/sjavac/Module.java ! src/share/classes/com/sun/tools/sjavac/Package.java ! src/share/classes/com/sun/tools/sjavac/ProblemException.java ! src/share/classes/com/sun/tools/sjavac/Source.java ! src/share/classes/com/sun/tools/sjavac/Transformer.java ! src/share/classes/com/sun/tools/sjavac/Util.java ! src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java ! src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java ! src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java ! src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java ! src/share/classes/com/sun/tools/sjavac/server/PortFile.java ! src/share/classes/com/sun/tools/sjavac/server/SysInfo.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java ! test/com/sun/javadoc/testAbstractMethod/pkg/A.java ! test/com/sun/javadoc/testAbstractMethod/pkg/B.java ! test/com/sun/javadoc/testAbstractMethod/pkg/C.java ! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java ! test/com/sun/javadoc/testDocRootLink/pkg1/C1.java ! test/com/sun/javadoc/testDocRootLink/pkg2/C2.java ! test/com/sun/javadoc/testLegacyTaglet/C.java ! test/com/sun/javadoc/testNavigation/pkg/A.java ! test/com/sun/javadoc/testNavigation/pkg/C.java ! test/com/sun/javadoc/testNavigation/pkg/E.java ! test/com/sun/javadoc/testNavigation/pkg/I.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java ! test/tools/javac/T6725036.java ! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java ! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java ! test/tools/javac/annotations/typeAnnotations/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java ! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java ! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java ! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java ! test/tools/javac/defaultMethods/static/Static01.java ! test/tools/javac/defaultMethods/static/Static02.java ! test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java ! test/tools/javac/defaultMethods/static/import/StaticImport1.java ! test/tools/javac/defaultMethods/static/import/StaticImport2.java ! test/tools/javac/defaultMethods/static/import/StaticImport3.java ! test/tools/javac/defaultMethods/static/import/pkg/A.java ! test/tools/javac/defaultMethods/static/import/pkg/B.java ! test/tools/javac/defaultMethods/static/import/pkg/C.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/diags/MessageFile.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java ! test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotInProfile.java ! test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java ! test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/lambda/DoubleStaticImport.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/Intersection02.java ! test/tools/javac/lambda/LambdaCapture06.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaExpr15.java ! test/tools/javac/lambda/MethodReference25.java ! test/tools/javac/lambda/MethodReference26.java ! test/tools/javac/lambda/MethodReference59.java ! test/tools/javac/lambda/MethodReference60.java ! test/tools/javac/lambda/TargetType51.java ! test/tools/javac/lambda/lambdaExecution/InInterface.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest2b.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/multicatch/Pos05.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/resolve/Pos.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/p/Foo.java Changeset: 232b9cf6303a Author: lana Date: 2013-12-25 10:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/232b9cf6303a Merge Changeset: a345cf28faca Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/a345cf28faca Added tag jdk8-b122 for changeset 232b9cf6303a ! .hgtags Changeset: d5aab8300d3b Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/d5aab8300d3b Added tag jdk8-b123 for changeset a345cf28faca ! .hgtags Changeset: 32fedf8c060f Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/32fedf8c060f Added tag jdk8u20-b00 for changeset d5aab8300d3b ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 19:54:09 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 03:54:09 +0000 Subject: hg: ppc-aix-port/stage/jaxp: 9 new changesets Message-ID: <20140123035430.7F322626AE@hg.openjdk.java.net> Changeset: 3e5bf0372a93 Author: joehw Date: 2013-12-12 11:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/3e5bf0372a93 8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification Reviewed-by: alanb, dfuchs, lancea ! src/javax/xml/stream/XMLOutputFactory.java Changeset: 9c7e3a68dc77 Author: lana Date: 2013-12-12 19:13 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/9c7e3a68dc77 Merge Changeset: fad4b4d28599 Author: lana Date: 2013-12-23 14:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/fad4b4d28599 Merge Changeset: 1bedbbce236a Author: joehw Date: 2013-12-20 09:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/1bedbbce236a 8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars Reviewed-by: dfuchs, lancea, ulfzibis ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 9a3986b21be4 Author: joehw Date: 2013-12-23 11:26 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/9a3986b21be4 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013 Reviewed-by: lancea, mchung ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java ! src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java ! src/com/sun/xml/internal/stream/Entity.java ! src/com/sun/xml/internal/stream/StaxXMLInputSource.java ! src/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/com/sun/xml/internal/stream/writers/WriterUtility.java ! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/javax/xml/XMLConstants.java ! src/javax/xml/parsers/SAXParser.java ! src/javax/xml/validation/Validator.java ! src/javax/xml/xpath/XPathException.java ! src/javax/xml/xpath/XPathFactory.java ! src/org/xml/sax/helpers/NewInstance.java ! src/org/xml/sax/helpers/ParserAdapter.java ! src/org/xml/sax/helpers/ParserFactory.java ! src/org/xml/sax/helpers/SecuritySupport.java ! src/org/xml/sax/helpers/XMLReaderFactory.java Changeset: 93bf25903af0 Author: lana Date: 2013-12-25 10:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/93bf25903af0 Merge Changeset: 4e35b5b6d2e5 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/4e35b5b6d2e5 Added tag jdk8-b122 for changeset 93bf25903af0 ! .hgtags Changeset: 1a28f773c894 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/1a28f773c894 Added tag jdk8-b123 for changeset 4e35b5b6d2e5 ! .hgtags Changeset: 866cf8ef1050 Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/866cf8ef1050 Added tag jdk8u20-b00 for changeset 1a28f773c894 ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 19:55:42 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 03:55:42 +0000 Subject: hg: ppc-aix-port/stage/nashorn: 10 new changesets Message-ID: <20140123035552.D1663626B1@hg.openjdk.java.net> Changeset: 752554d45a07 Author: sundar Date: 2013-12-09 09:48 +0530 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/752554d45a07 8029612: the typeErrorThrower field in ScriptFunctionImpl cannot be static and common to all Globals Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java Changeset: 739f3abdfa55 Author: sundar Date: 2013-12-09 09:53 +0530 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/739f3abdfa55 Merge Changeset: 4706897b4dec Author: attila Date: 2013-12-09 10:52 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/4706897b4dec 8029467: Widening of booleans causes bad results Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8029467.js + test/script/basic/JDK-8029467.js.EXPECTED Changeset: 18edd7a1b166 Author: lagergren Date: 2013-12-11 18:09 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/18edd7a1b166 8029780: "ant externals" broke our test harness with the latest version of the octane benchmarks Reviewed-by: attila, sundar ! make/build-benchmark.xml ! test/script/basic/compile-octane-splitter.js.EXPECTED ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js Changeset: e452a3797290 Author: sundar Date: 2013-12-12 09:18 +0530 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/e452a3797290 Merge Changeset: 0225a7ca37ab Author: lana Date: 2013-12-12 19:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/0225a7ca37ab Merge Changeset: 9d112a0e7df7 Author: lana Date: 2013-12-23 14:46 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/9d112a0e7df7 Merge Changeset: 688f4167f921 Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/688f4167f921 Added tag jdk8-b122 for changeset 9d112a0e7df7 ! .hgtags Changeset: 0b4301c79225 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/0b4301c79225 Added tag jdk8-b123 for changeset 688f4167f921 ! .hgtags Changeset: 2cda3335666f Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/2cda3335666f Added tag jdk8u20-b00 for changeset 0b4301c79225 ! .hgtags From vladimir.kozlov at oracle.com Wed Jan 22 20:06:49 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 04:06:49 +0000 Subject: hg: ppc-aix-port/stage/jdk: 45 new changesets Message-ID: <20140123041558.1B9F1626B2@hg.openjdk.java.net> Changeset: c8c4aef922ff Author: vadim Date: 2013-12-13 11:49 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/c8c4aef922ff 8029628: Many graphic artifacts Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 6ecbfe5e211b Author: lana Date: 2013-12-19 10:23 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/6ecbfe5e211b Merge Changeset: 9e0e8eed676a Author: pchelko Date: 2013-12-06 17:47 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/9e0e8eed676a 8029565: java.awt.dnd.InvalidDnDOperationException: data translation failed on file drop Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/solaris/classes/sun/awt/X11/XDataTransferer.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/SourceFileListFrame.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/TargetFileListFrame.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.html + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java + test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListTransferable.java Changeset: 152cf399f16f Author: serb Date: 2013-12-11 22:17 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/152cf399f16f 8029045: Regression - Unsatisfied Link Error when the Java Access Bridge is started Summary: Rename native function name; fix make to rebuild jni header file Reviewed-by: erikj, tbell Contributed-by: peter.brunet at oracle.com ! make/CompileJavaClasses.gmk Changeset: 06c655658b89 Author: serb Date: 2013-12-12 16:30 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/06c655658b89 8001472: api/java_awt/Window/indexTGF_* tests fail because expected colors aren't equal Reviewed-by: anthony, azvegint ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java Changeset: 78d395c7c479 Author: lana Date: 2013-12-12 20:04 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/78d395c7c479 Merge - make/data/cryptopolicy/limited/LIMITED - make/data/cryptopolicy/unlimited/UNLIMITED - test/com/sun/jmx/snmp/NoInfoLeakTest.java - test/com/sun/tools/attach/AgentSetup.sh - test/com/sun/tools/attach/ApplicationSetup.sh - test/com/sun/tools/attach/BasicTests.sh - test/com/sun/tools/attach/CommonSetup.sh - test/com/sun/tools/attach/PermissionTests.sh - test/com/sun/tools/attach/ProviderTests.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh - test/java/rmi/reliability/benchmark/runRmiBench.sh - test/java/rmi/reliability/benchmark/runSerialBench.sh Changeset: 20d504a20a87 Author: azvegint Date: 2013-12-13 14:29 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/20d504a20a87 8029923: Many Swing tests and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load native GTK libraries" Reviewed-by: anthony, serb ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h Changeset: c8ec5c070592 Author: azvegint Date: 2013-12-18 11:09 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/c8ec5c070592 8029263: user's default browser can not launch after we click the button, and there is an IOException shown in the log text (java.io.IOException) Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c ! test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java Changeset: 4ee27281d27d Author: lana Date: 2013-12-19 10:24 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/4ee27281d27d Merge Changeset: f8da1f34c65c Author: darcy Date: 2013-12-06 11:28 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/f8da1f34c65c 8023471: Add compatibility note to AnnotatedElement Reviewed-by: smarks, jfranck, abuckley ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: d6c4ae56c079 Author: juh Date: 2013-12-06 11:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/d6c4ae56c079 8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward() Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 9e579a2329c0 Author: michaelm Date: 2013-12-09 13:05 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/9e579a2329c0 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname Reviewed-by: alanb, chegar ! src/share/classes/java/net/URLPermission.java + test/java/net/URLPermission/OpenURL.java ! test/java/net/URLPermission/URLPermissionTest.java Changeset: 23a7524d930c Author: mfang Date: 2013-12-09 15:01 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/23a7524d930c 8025974: l10n for policytool Reviewed-by: naoto, leifs, yhuang ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java Changeset: fe3383582427 Author: rriggs Date: 2013-12-11 16:52 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/fe3383582427 8029551: Add value-type notice to java.time classes Summary: Add warning about identity of value types and reference to ValueBased.html Reviewed-by: briangoetz, smarks, scolebourne ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java Changeset: 1298e476729c Author: michaelm Date: 2013-12-11 15:26 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/1298e476729c 8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method Reviewed-by: mduigou Contributed-by: michael.mcmahon at oracle.com ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java Changeset: 1970e3c3d202 Author: michaelm Date: 2013-12-11 15:27 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/1970e3c3d202 8029696: Broken doc links to package-summary.html#NonInterference in java.util.stream Reviewed-by: mduigou ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java Changeset: 01b11184bcf9 Author: mfang Date: 2013-12-11 21:22 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/01b11184bcf9 8026115: [zh_CN] inproper translation in output of jarsigner command Reviewed-by: naoto, yhuang ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java Changeset: 23b89bd740e9 Author: lana Date: 2013-12-12 19:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/23b89bd740e9 Merge Changeset: a7ed72627c3f Author: mduigou Date: 2013-12-13 13:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/a7ed72627c3f 8029055: Map.merge implementations should refuse null value param Reviewed-by: briangoetz, dl ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java Changeset: 26028cb56c68 Author: mduigou Date: 2013-12-13 13:35 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/26028cb56c68 8030016: HashMap.computeIfAbsent generates spurious access event Reviewed-by: psandoz, bchristi ! src/share/classes/java/util/HashMap.java + test/java/util/LinkedHashMap/ComputeIfAbsentAccessOrder.java ! test/java/util/Map/Defaults.java Changeset: 6c343d3d2721 Author: smarks Date: 2013-12-13 18:08 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/6c343d3d2721 8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons Reviewed-by: mchung, dmocek ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/resources/rmic.properties Changeset: 8e133b86b9f8 Author: mduigou Date: 2013-12-17 09:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/8e133b86b9f8 8029795: LinkedHashMap.getOrDefault() doesn't update access order. Reviewed-by: psandoz ! src/share/classes/java/util/LinkedHashMap.java ! test/java/util/LinkedHashMap/Basic.java Changeset: 4fa27233a3e9 Author: mfang Date: 2013-12-17 14:13 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/4fa27233a3e9 7090826: Newly added codes need to be localized into pt_BR in LocaleNames Reviewed-by: okutsu ! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 68c31754f925 Author: vinnie Date: 2013-12-17 23:03 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/68c31754f925 8029788: Certificate validation - java.lang.ClassCastException Reviewed-by: xuelei, mullan, weijun ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9211877b25ba Author: mfang Date: 2013-12-17 23:33 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/9211877b25ba 8026741: jdk8 l10n resource file translation update 5 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/keytool/Resources_es.java ! src/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/share/classes/sun/security/tools/keytool/Resources_it.java ! src/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties Changeset: 8d35f0985dd7 Author: xuelei Date: 2013-12-18 16:46 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/8d35f0985dd7 7093640: Enable client-side TLS 1.2 by default Reviewed-by: weijun, mullan, wetmore ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: e2bdddb8bedf Author: dl Date: 2013-12-19 10:31 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/e2bdddb8bedf 8026155: Enhance ForkJoin pool Reviewed-by: chegar, alanb, ahgross ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: c841815be720 Author: chegar Date: 2013-12-19 10:38 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/c841815be720 Merge Changeset: a2339db970e0 Author: lana Date: 2013-12-19 10:26 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/a2339db970e0 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 2f31ddf65e74 Author: lana Date: 2013-12-23 14:45 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/2f31ddf65e74 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 75142ce752da Author: malenkov Date: 2013-12-23 16:24 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/75142ce752da 8030118: Document listeners fired outside document lock Reviewed-by: art, serb ! src/share/classes/javax/swing/text/AbstractDocument.java - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java + test/javax/swing/text/AbstractDocument/8030118/Test8030118.java Changeset: 8b5985f1a0b5 Author: lana Date: 2013-12-25 11:14 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/8b5985f1a0b5 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 73473e9dfc46 Author: joehw Date: 2013-12-20 09:56 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/73473e9dfc46 8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars Reviewed-by: dfuchs, lancea, ulfzibis + test/javax/xml/jaxp/parsers/8029955/EntityScannerTest.java Changeset: 7186275e6ef1 Author: rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/7186275e6ef1 8030002: Enhance deserialization using readObject Reviewed-by: sherman, chegar, scolebourne ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java Changeset: 39a02b18b386 Author: rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/39a02b18b386 8029909: Clarify equals/hashcode behavior for java.time types Summary: Document the behavior of equals and hashcode in java.time.chrono date types Reviewed-by: sherman, scolebourne ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: aef6c726810e Author: mullan Date: 2013-12-23 14:03 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/aef6c726810e 8030813: Signed applet fails to load when CRLs are stored in an LDAP directory Summary: Skip JNDI application resource lookup to avoid recursive JAR validation Reviewed-by: vinnie, herrick ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java Changeset: f3c714eeef6c Author: mullan Date: 2013-12-23 14:05 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/f3c714eeef6c Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: 71ce5e56ca60 Author: lana Date: 2013-12-25 10:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/71ce5e56ca60 Merge Changeset: 1a3de3cdc684 Author: lana Date: 2013-12-26 12:04 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/1a3de3cdc684 8029235: Update copyright year to match last edit in jdk8 jdk repository for 2013 Summary: updated files with 2011, 2012 and 2013 years according to the file's last updated date Reviewed-by: tbell, lancea, chegar ! make/BuildJdk.gmk ! make/Bundles.gmk ! make/CompileJavaClasses.gmk ! make/CompileLaunchers.gmk ! make/CopyIntoClasses.gmk ! make/CopySamples.gmk ! make/GenerateData.gmk ! make/Makefile ! make/data/characterdata/CharacterData00.java.template ! make/data/characterdata/CharacterData01.java.template ! make/data/characterdata/CharacterData02.java.template ! make/data/characterdata/CharacterData0E.java.template ! make/data/characterdata/CharacterDataLatin1.java.template ! make/data/characterdata/CharacterDataPrivateUse.java.template ! make/data/characterdata/CharacterDataUndefined.java.template ! make/data/charsetmapping/DoubleByte-X.java.template ! make/data/charsetmapping/SingleByte-X.java.template ! make/data/dtdbuilder/html32.dtd ! make/data/jdwp/jdwp.spec ! make/data/swingbeaninfo/SwingBeanInfo.template ! make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java ! make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java ! make/data/tzdata/gmt ! make/data/tzdata/jdk11_backward ! make/gendata/GendataFontConfig.gmk ! make/gendata/GendataHtml32dtd.gmk ! make/gensrc/GensrcBuffer.gmk ! make/gensrc/GensrcCLDR.gmk ! make/gensrc/GensrcCharacterData.gmk ! make/gensrc/GensrcCharsetCoder.gmk ! make/gensrc/GensrcCharsetMapping.gmk ! make/gensrc/GensrcExceptions.gmk ! make/gensrc/GensrcJDWP.gmk ! make/gensrc/GensrcJObjC.gmk ! make/gensrc/GensrcLocaleDataMetaInfo.gmk ! make/gensrc/GensrcMisc.gmk ! make/gensrc/GensrcProperties.gmk ! make/gensrc/GensrcSwing.gmk ! make/gensrc/GensrcX11Wrappers.gmk ! make/mapfiles/launchers/mapfile-sparc ! make/mapfiles/launchers/mapfile-sparcv9 ! make/mapfiles/launchers/mapfile-x86 ! make/mapfiles/launchers/mapfile-x86_64 ! make/mapfiles/libattach/mapfile-linux ! make/mapfiles/libattach/mapfile-solaris ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt/mapfile-vers ! make/mapfiles/libawt/mapfile-vers-linux ! make/mapfiles/libawt_headless/mapfile-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! make/mapfiles/libdcpr/mapfile-vers ! make/mapfiles/libdt_socket/mapfile-vers ! make/mapfiles/libfontmanager/mapfile-vers ! make/mapfiles/libfontmanager/mapfile-vers.openjdk ! make/mapfiles/libhprof/mapfile-vers ! make/mapfiles/libinstrument/mapfile-vers ! make/mapfiles/libj2gss/mapfile-vers ! make/mapfiles/libj2pcsc/mapfile-vers ! make/mapfiles/libj2ucrypto/mapfile-vers ! make/mapfiles/libjaas/mapfile-vers ! make/mapfiles/libjava_crw_demo/mapfile-vers ! make/mapfiles/libjawt/mapfile-vers ! make/mapfiles/libjdga/mapfile-vers ! make/mapfiles/libjdwp/mapfile-vers ! make/mapfiles/libjli/mapfile-vers ! make/mapfiles/libjpeg/mapfile-vers ! make/mapfiles/libjpeg/mapfile-vers-closed ! make/mapfiles/libjsdt/mapfile-vers ! make/mapfiles/libjsound/mapfile-vers ! make/mapfiles/libjsoundalsa/mapfile-vers ! make/mapfiles/libkcms/mapfile-vers ! make/mapfiles/liblcms/mapfile-vers ! make/mapfiles/libmlib_image/mapfile-vers ! make/mapfiles/libnet/mapfile-vers ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! make/mapfiles/libnpt/mapfile-vers ! make/mapfiles/libsctp/mapfile-vers ! make/mapfiles/libsplashscreen/mapfile-vers ! make/mapfiles/libsunec/mapfile-vers ! make/mapfiles/libt2k/mapfile-vers ! make/mapfiles/libunpack/mapfile-vers ! make/mapfiles/libunpack/mapfile-vers-unpack200 ! make/mapfiles/libverify/mapfile-vers ! make/mapfiles/libzip/mapfile-vers ! make/netbeans/common/architectures/arch-x86_64.properties ! make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/closed-share-sources.ent ! make/netbeans/common/demo-view.ent ! make/netbeans/common/make.xml ! make/netbeans/common/properties.ent ! make/netbeans/common/share-sources.ent ! make/netbeans/common/shared.xml ! make/netbeans/common/unix-sources.ent ! make/netbeans/common/windows-sources.ent ! make/netbeans/j2se/build.xml ! make/netbeans/jmx/build.properties ! make/non-build-utils/reorder/Makefile ! make/non-build-utils/reorder/tests/Exit.java ! make/non-build-utils/reorder/tests/Hello.java ! make/non-build-utils/reorder/tests/IntToString.java ! make/non-build-utils/reorder/tests/JHello.java ! make/non-build-utils/reorder/tests/LoadFrame.java ! make/non-build-utils/reorder/tests/LoadJFrame.java ! make/non-build-utils/reorder/tests/LoadToolkit.java ! make/non-build-utils/reorder/tests/Null.java ! make/non-build-utils/reorder/tests/Sleep.java ! make/non-build-utils/reorder/tools/Combine.java ! make/non-build-utils/reorder/tools/MaxTime.java ! make/non-build-utils/reorder/tools/mcount.c ! make/non-build-utils/reorder/tools/remove_mcount.c ! make/non-build-utils/sharing/tests/GHello.java ! make/non-build-utils/sharing/tests/Hello.java ! make/non-build-utils/sharing/tests/JHello.java ! make/non-build-utils/src/build/tools/commentchecker/CommentChecker.java ! make/non-build-utils/src/build/tools/dirdiff/DirDiff.java ! make/src/classes/build/tools/addjsum/AddJsum.java ! make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java ! make/src/classes/build/tools/charsetmapping/DBCS.java ! make/src/classes/build/tools/charsetmapping/EUC_TW.java ! make/src/classes/build/tools/charsetmapping/HKSCS.java ! make/src/classes/build/tools/charsetmapping/JIS0213.java ! make/src/classes/build/tools/charsetmapping/Main.java ! make/src/classes/build/tools/charsetmapping/SBCS.java ! make/src/classes/build/tools/charsetmapping/Utils.java ! make/src/classes/build/tools/classfile/RemoveMethods.java ! make/src/classes/build/tools/cldrconverter/BundleGenerator.java ! make/src/classes/build/tools/cldrconverter/Container.java ! make/src/classes/build/tools/cldrconverter/CopyrightHeaders.java ! make/src/classes/build/tools/cldrconverter/Entry.java ! make/src/classes/build/tools/cldrconverter/IgnoredContainer.java ! make/src/classes/build/tools/cldrconverter/KeyContainer.java ! make/src/classes/build/tools/cldrconverter/MetaZonesParseHandler.java ! make/src/classes/build/tools/cldrconverter/NumberingSystemsParseHandler.java ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/src/classes/build/tools/cldrconverter/StringArrayElement.java ! make/src/classes/build/tools/cldrconverter/StringArrayEntry.java ! make/src/classes/build/tools/cldrconverter/StringEntry.java ! make/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java ! make/src/classes/build/tools/compilefontconfig/CompileFontConfig.java ! make/src/classes/build/tools/compileproperties/CompileProperties.java ! make/src/classes/build/tools/dtdbuilder/DTDBuilder.java ! make/src/classes/build/tools/dtdbuilder/DTDInputStream.java ! make/src/classes/build/tools/dtdbuilder/DTDParser.java ! make/src/classes/build/tools/dtdbuilder/PublicMapping.java ! make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/src/classes/build/tools/generatebreakiteratordata/CharSet.java ! make/src/classes/build/tools/generatebreakiteratordata/CharacterCategory.java ! make/src/classes/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! make/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java ! make/src/classes/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java ! make/src/classes/build/tools/generatecharacter/GenerateCharacter.java ! make/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java ! make/src/classes/build/tools/generatecharacter/PropList.java ! make/src/classes/build/tools/generatecharacter/SpecialCaseMap.java ! make/src/classes/build/tools/generatecharacter/UnicodeSpec.java ! make/src/classes/build/tools/generatecharacter/Utility.java ! make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java ! make/src/classes/build/tools/generatenimbus/AbstractGradient.java ! make/src/classes/build/tools/generatenimbus/Border.java ! make/src/classes/build/tools/generatenimbus/Canvas.java ! make/src/classes/build/tools/generatenimbus/ComponentColor.java ! make/src/classes/build/tools/generatenimbus/Dimension.java ! make/src/classes/build/tools/generatenimbus/Ellipse.java ! make/src/classes/build/tools/generatenimbus/Generator.java ! make/src/classes/build/tools/generatenimbus/Gradient.java ! make/src/classes/build/tools/generatenimbus/GradientStop.java ! make/src/classes/build/tools/generatenimbus/Insets.java ! make/src/classes/build/tools/generatenimbus/Layer.java ! make/src/classes/build/tools/generatenimbus/Matte.java ! make/src/classes/build/tools/generatenimbus/ObjectFactory.java ! make/src/classes/build/tools/generatenimbus/Paint.java ! make/src/classes/build/tools/generatenimbus/PainterGenerator.java ! make/src/classes/build/tools/generatenimbus/Path.java ! make/src/classes/build/tools/generatenimbus/Point.java ! make/src/classes/build/tools/generatenimbus/RadialGradient.java ! make/src/classes/build/tools/generatenimbus/Rectangle.java ! make/src/classes/build/tools/generatenimbus/Shape.java ! make/src/classes/build/tools/generatenimbus/SynthModel.java ! make/src/classes/build/tools/generatenimbus/Typeface.java ! make/src/classes/build/tools/generatenimbus/UIColor.java ! make/src/classes/build/tools/generatenimbus/UIComponent.java ! make/src/classes/build/tools/generatenimbus/UIDefault.java ! make/src/classes/build/tools/generatenimbus/UIFont.java ! make/src/classes/build/tools/generatenimbus/UIIconRegion.java ! make/src/classes/build/tools/generatenimbus/UIProperty.java ! make/src/classes/build/tools/generatenimbus/UIRegion.java ! make/src/classes/build/tools/generatenimbus/UIState.java ! make/src/classes/build/tools/generatenimbus/UIStateType.java ! make/src/classes/build/tools/generatenimbus/UIStyle.java ! make/src/classes/build/tools/generatenimbus/Utils.java ! make/src/classes/build/tools/hasher/Hasher.java ! make/src/classes/build/tools/icondata/osxapp/ToBin.java ! make/src/classes/build/tools/jarreorder/JarReorder.java ! make/src/classes/build/tools/jdwpgen/AbstractCommandNode.java ! make/src/classes/build/tools/jdwpgen/AbstractGroupNode.java ! make/src/classes/build/tools/jdwpgen/AbstractNamedNode.java ! make/src/classes/build/tools/jdwpgen/AbstractSimpleNode.java ! make/src/classes/build/tools/jdwpgen/AbstractSimpleTypeNode.java ! make/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java ! make/src/classes/build/tools/jdwpgen/AbstractTypeNode.java ! make/src/classes/build/tools/jdwpgen/AltNode.java ! make/src/classes/build/tools/jdwpgen/ArrayObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/src/classes/build/tools/jdwpgen/ArrayTypeNode.java ! make/src/classes/build/tools/jdwpgen/BooleanTypeNode.java ! make/src/classes/build/tools/jdwpgen/ByteTypeNode.java ! make/src/classes/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ClassObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ClassTypeNode.java ! make/src/classes/build/tools/jdwpgen/CommandNode.java ! make/src/classes/build/tools/jdwpgen/CommandSetNode.java ! make/src/classes/build/tools/jdwpgen/CommentNode.java ! make/src/classes/build/tools/jdwpgen/ConstantNode.java ! make/src/classes/build/tools/jdwpgen/ConstantSetNode.java ! make/src/classes/build/tools/jdwpgen/Context.java ! make/src/classes/build/tools/jdwpgen/ErrorNode.java ! make/src/classes/build/tools/jdwpgen/ErrorSetNode.java ! make/src/classes/build/tools/jdwpgen/EventNode.java ! make/src/classes/build/tools/jdwpgen/FieldTypeNode.java ! make/src/classes/build/tools/jdwpgen/FrameTypeNode.java ! make/src/classes/build/tools/jdwpgen/GroupNode.java ! make/src/classes/build/tools/jdwpgen/IntTypeNode.java ! make/src/classes/build/tools/jdwpgen/InterfaceTypeNode.java ! make/src/classes/build/tools/jdwpgen/LocationTypeNode.java ! make/src/classes/build/tools/jdwpgen/LongTypeNode.java ! make/src/classes/build/tools/jdwpgen/Main.java ! make/src/classes/build/tools/jdwpgen/MethodTypeNode.java ! make/src/classes/build/tools/jdwpgen/NameNode.java ! make/src/classes/build/tools/jdwpgen/NameValueNode.java ! make/src/classes/build/tools/jdwpgen/Node.java ! make/src/classes/build/tools/jdwpgen/ObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/OutNode.java ! make/src/classes/build/tools/jdwpgen/Parse.java ! make/src/classes/build/tools/jdwpgen/ReferenceIDTypeNode.java ! make/src/classes/build/tools/jdwpgen/ReferenceTypeNode.java ! make/src/classes/build/tools/jdwpgen/RepeatNode.java ! make/src/classes/build/tools/jdwpgen/ReplyNode.java ! make/src/classes/build/tools/jdwpgen/RootNode.java ! make/src/classes/build/tools/jdwpgen/SelectNode.java ! make/src/classes/build/tools/jdwpgen/StringObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/StringTypeNode.java ! make/src/classes/build/tools/jdwpgen/TaggedObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/ThreadObjectTypeNode.java ! make/src/classes/build/tools/jdwpgen/TypeNode.java ! make/src/classes/build/tools/jdwpgen/UntaggedValueTypeNode.java ! make/src/classes/build/tools/jdwpgen/ValueTypeNode.java ! make/src/classes/build/tools/spp/Spp.java ! make/src/classes/build/tools/stripproperties/StripProperties.java ! make/src/classes/build/tools/swingbeaninfo/DocBeanInfo.java ! make/src/classes/build/tools/swingbeaninfo/GenDocletBeanInfo.java ! make/src/classes/build/tools/swingbeaninfo/GenSwingBeanInfo.java ! make/src/native/add_gnu_debuglink/add_gnu_debuglink.c ! make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c ! src/macosx/bin/java_md_macosx.c ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/macosx/classes/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/apple/laf/JRSUIControl.java ! src/macosx/classes/apple/laf/JRSUIFocus.java ! src/macosx/classes/apple/laf/JRSUIState.java ! src/macosx/classes/apple/laf/JRSUIStateFactory.java ! src/macosx/classes/apple/laf/JRSUIUtils.java ! src/macosx/classes/com/apple/eawt/AboutHandler.java ! src/macosx/classes/com/apple/eawt/AppEvent.java ! src/macosx/classes/com/apple/eawt/AppEventListener.java ! src/macosx/classes/com/apple/eawt/AppForegroundListener.java ! src/macosx/classes/com/apple/eawt/AppHiddenListener.java ! src/macosx/classes/com/apple/eawt/AppReOpenedListener.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eawt/ApplicationAdapter.java ! src/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java ! src/macosx/classes/com/apple/eawt/ApplicationEvent.java ! src/macosx/classes/com/apple/eawt/ApplicationListener.java ! src/macosx/classes/com/apple/eawt/FullScreenAdapter.java ! src/macosx/classes/com/apple/eawt/FullScreenListener.java ! src/macosx/classes/com/apple/eawt/FullScreenUtilities.java ! src/macosx/classes/com/apple/eawt/OpenFilesHandler.java ! src/macosx/classes/com/apple/eawt/OpenURIHandler.java ! src/macosx/classes/com/apple/eawt/PreferencesHandler.java ! src/macosx/classes/com/apple/eawt/PrintFilesHandler.java ! src/macosx/classes/com/apple/eawt/QuitHandler.java ! src/macosx/classes/com/apple/eawt/QuitResponse.java ! src/macosx/classes/com/apple/eawt/QuitStrategy.java ! src/macosx/classes/com/apple/eawt/ScreenSleepListener.java ! src/macosx/classes/com/apple/eawt/SystemSleepListener.java ! src/macosx/classes/com/apple/eawt/UserSessionListener.java ! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java ! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/macosx/classes/com/apple/eawt/_AppMiscHandlers.java ! src/macosx/classes/com/apple/eawt/event/GestureAdapter.java ! src/macosx/classes/com/apple/eawt/event/GestureEvent.java ! src/macosx/classes/com/apple/eawt/event/GestureListener.java ! src/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java ! src/macosx/classes/com/apple/eawt/event/GesturePhaseListener.java ! src/macosx/classes/com/apple/eawt/event/GestureUtilities.java ! src/macosx/classes/com/apple/eawt/event/MagnificationEvent.java ! src/macosx/classes/com/apple/eawt/event/MagnificationListener.java ! src/macosx/classes/com/apple/eawt/event/RotationEvent.java ! src/macosx/classes/com/apple/eawt/event/RotationListener.java ! src/macosx/classes/com/apple/eawt/event/SwipeEvent.java ! src/macosx/classes/com/apple/eawt/event/SwipeListener.java ! src/macosx/classes/com/apple/laf/AquaBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java ! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java ! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! src/macosx/classes/com/apple/laf/AquaButtonRadioUI.java ! src/macosx/classes/com/apple/laf/AquaButtonToggleUI.java ! src/macosx/classes/com/apple/laf/AquaButtonUI.java ! src/macosx/classes/com/apple/laf/AquaCaret.java ! src/macosx/classes/com/apple/laf/AquaComboBoxButton.java ! src/macosx/classes/com/apple/laf/AquaComboBoxPopup.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java ! src/macosx/classes/com/apple/laf/AquaEditorPaneUI.java ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaFocus.java ! src/macosx/classes/com/apple/laf/AquaFocusHandler.java ! src/macosx/classes/com/apple/laf/AquaFonts.java ! src/macosx/classes/com/apple/laf/AquaGroupBorder.java ! src/macosx/classes/com/apple/laf/AquaHighlighter.java ! src/macosx/classes/com/apple/laf/AquaIcon.java ! src/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameBorderMetrics.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameDockIconUI.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameManager.java ! src/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java ! src/macosx/classes/com/apple/laf/AquaLabelUI.java ! src/macosx/classes/com/apple/laf/AquaListUI.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaMenuBarBorder.java ! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java ! src/macosx/classes/com/apple/laf/AquaMenuBorder.java ! src/macosx/classes/com/apple/laf/AquaMenuItemUI.java ! src/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/macosx/classes/com/apple/laf/AquaMenuUI.java ! src/macosx/classes/com/apple/laf/AquaMnemonicHandler.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/AquaOptionPaneUI.java ! src/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java ! src/macosx/classes/com/apple/laf/AquaPopupMenuUI.java ! src/macosx/classes/com/apple/laf/AquaProgressBarUI.java ! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java ! src/macosx/classes/com/apple/laf/AquaScrollBarUI.java ! src/macosx/classes/com/apple/laf/AquaScrollPaneUI.java ! src/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java ! src/macosx/classes/com/apple/laf/AquaSliderUI.java ! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java ! src/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java ! src/macosx/classes/com/apple/laf/AquaSplitPaneUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java ! src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java ! src/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/macosx/classes/com/apple/laf/AquaTableUI.java ! src/macosx/classes/com/apple/laf/AquaTextAreaUI.java ! src/macosx/classes/com/apple/laf/AquaTextFieldBorder.java ! src/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java ! src/macosx/classes/com/apple/laf/AquaTextFieldSearch.java ! src/macosx/classes/com/apple/laf/AquaTextFieldUI.java ! src/macosx/classes/com/apple/laf/AquaTextPaneUI.java ! src/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/macosx/classes/com/apple/laf/AquaToolTipUI.java ! src/macosx/classes/com/apple/laf/AquaTreeUI.java ! src/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/macosx/classes/com/apple/laf/ClientPropertyApplicator.java ! src/macosx/classes/com/apple/laf/ScreenMenuBar.java ! src/macosx/classes/com/apple/laf/ScreenMenuBarProvider.java ! src/macosx/classes/com/apple/laf/ScreenMenuItem.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemUI.java ! src/macosx/classes/com/apple/laf/ScreenMenuPropertyHandler.java ! src/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties ! src/macosx/classes/com/apple/laf/resources/aqua_de.properties ! src/macosx/classes/com/apple/laf/resources/aqua_es.properties ! src/macosx/classes/com/apple/laf/resources/aqua_fr.properties ! src/macosx/classes/com/apple/laf/resources/aqua_it.properties ! src/macosx/classes/com/apple/laf/resources/aqua_ja.properties ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties ! src/macosx/classes/com/apple/laf/resources/aqua_sv.properties ! src/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties ! src/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/FullScreenCapable.java ! src/macosx/classes/sun/awt/fontconfigs/macosx.fontconfig.properties ! src/macosx/classes/sun/font/CCharToGlyphMapper.java ! src/macosx/classes/sun/font/CFont.java ! src/macosx/classes/sun/font/CFontConfiguration.java ! src/macosx/classes/sun/font/CFontManager.java ! src/macosx/classes/sun/font/CStrikeDisposer.java ! src/macosx/classes/sun/java2d/BackBufferCapsProvider.java ! src/macosx/classes/sun/java2d/CRenderer.java ! src/macosx/classes/sun/java2d/CompositeCRenderer.java ! src/macosx/classes/sun/java2d/DataBufferNIOInt.java ! src/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java ! src/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java ! src/macosx/classes/sun/lwawt/PlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/macosx/classes/sun/lwawt/macosx/CAccessible.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibleText.java ! src/macosx/classes/sun/lwawt/macosx/CClipboard.java ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java ! src/macosx/classes/sun/lwawt/macosx/CCustomCursor.java ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! src/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/macosx/classes/sun/lwawt/macosx/CImage.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuBar.java ! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPopupMenu.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDevice.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphics.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphicsConfig.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterJobDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterPageDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterSurfaceData.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/macosx/classes/sun/lwawt/macosx/CSystemTray.java ! src/macosx/classes/sun/lwawt/macosx/CTextPipe.java ! src/macosx/classes/sun/lwawt/macosx/CThreading.java ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java ! src/macosx/classes/sun/lwawt/macosx/event/NSEvent.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/macosx/native/com/apple/laf/AquaFileView.m ! src/macosx/native/com/apple/laf/AquaLookAndFeel.m ! src/macosx/native/com/apple/laf/AquaNativeResources.m ! src/macosx/native/com/apple/laf/JRSUIConstantSync.h ! src/macosx/native/com/apple/laf/JRSUIConstantSync.m ! src/macosx/native/com/apple/laf/JRSUIFocus.m ! src/macosx/native/com/apple/laf/ScreenMenu.h ! src/macosx/native/com/apple/laf/ScreenMenu.m ! src/macosx/native/com/apple/laf/ScreenPopupFactory.m ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiIn.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiOut.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.h ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.cpp ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.h ! src/macosx/native/java/util/SCDynamicStoreConfig.m ! src/macosx/native/jobjc/src/core/native/SEL.m ! src/macosx/native/sun/awt/AWTSurfaceLayers.h ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/ApplicationDelegate.h ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.h ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CDataTransferer.h ! src/macosx/native/sun/awt/CDataTransferer.m ! src/macosx/native/sun/awt/CDesktopPeer.m ! src/macosx/native/sun/awt/CDragSource.h ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! src/macosx/native/sun/awt/CDropTarget.h ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CDropTargetContextPeer.m ! src/macosx/native/sun/awt/CFRetainedResource.m ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CGraphicsConfig.m ! src/macosx/native/sun/awt/CGraphicsEnv.m ! src/macosx/native/sun/awt/CImage.m ! src/macosx/native/sun/awt/CInputMethod.m ! src/macosx/native/sun/awt/CMenu.h ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuBar.h ! src/macosx/native/sun/awt/CMenuBar.m ! src/macosx/native/sun/awt/CMenuComponent.h ! src/macosx/native/sun/awt/CMenuComponent.m ! src/macosx/native/sun/awt/CMenuItem.h ! src/macosx/native/sun/awt/CPopupMenu.h ! src/macosx/native/sun/awt/CPopupMenu.m ! src/macosx/native/sun/awt/CPrinterJob.m ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/CSystemColors.h ! src/macosx/native/sun/awt/CSystemColors.m ! src/macosx/native/sun/awt/CTextPipe.m ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m ! src/macosx/native/sun/awt/CWrapper.h ! src/macosx/native/sun/awt/DnDUtilities.h ! src/macosx/native/sun/awt/DnDUtilities.m ! src/macosx/native/sun/awt/GeomUtilities.h ! src/macosx/native/sun/awt/GeomUtilities.m ! src/macosx/native/sun/awt/ImageSurfaceData.h ! src/macosx/native/sun/awt/ImageSurfaceData.m ! src/macosx/native/sun/awt/InitIDs.h ! src/macosx/native/sun/awt/InitIDs.m ! src/macosx/native/sun/awt/JavaAccessibilityAction.h ! src/macosx/native/sun/awt/JavaAccessibilityAction.m ! src/macosx/native/sun/awt/JavaAccessibilityUtilities.h ! src/macosx/native/sun/awt/JavaAccessibilityUtilities.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.h ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/JavaTextAccessibility.h ! src/macosx/native/sun/awt/JavaTextAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.h ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/OSVersion.h ! src/macosx/native/sun/awt/OSVersion.m ! src/macosx/native/sun/awt/PrintModel.h ! src/macosx/native/sun/awt/PrintModel.m ! src/macosx/native/sun/awt/PrinterSurfaceData.h ! src/macosx/native/sun/awt/PrinterSurfaceData.m ! src/macosx/native/sun/awt/PrinterView.h ! src/macosx/native/sun/awt/QuartzRenderer.m ! src/macosx/native/sun/awt/QuartzSurfaceData.h ! src/macosx/native/sun/awt/QuartzSurfaceData.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/awt/awt_DrawingSurface.m ! src/macosx/native/sun/awt/jawt.m ! src/macosx/native/sun/awt/splashscreen/splashscreen_config.h ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/macosx/native/sun/font/AWTFont.h ! src/macosx/native/sun/font/AWTFont.m ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/macosx/native/sun/font/CGGlyphImages.h ! src/macosx/native/sun/font/CGGlyphOutlines.h ! src/macosx/native/sun/font/CGGlyphOutlines.m ! src/macosx/native/sun/font/CoreTextSupport.h ! src/macosx/native/sun/font/CoreTextSupport.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.h ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.h ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/macosx/native/sun/java2d/opengl/J2D_GL/cglext.h ! src/macosx/native/sun/java2d/opengl/OGLFuncs_md.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m ! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! src/share/back/SDE.c ! src/share/back/ThreadGroupReferenceImpl.c ! src/share/back/commonRef.c ! src/share/back/eventFilter.c ! src/share/back/export/sys.h ! src/share/back/outStream.c ! src/share/back/transport.c ! src/share/back/util.c ! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java ! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java ! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java ! src/share/classes/com/sun/beans/decoder/CharElementHandler.java ! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java ! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java ! src/share/classes/com/sun/beans/decoder/ElementHandler.java ! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java ! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java ! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java ! src/share/classes/com/sun/beans/decoder/IntElementHandler.java ! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java ! src/share/classes/com/sun/beans/decoder/LongElementHandler.java ! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java ! src/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/share/classes/com/sun/beans/decoder/NullElementHandler.java ! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java ! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java ! src/share/classes/com/sun/beans/decoder/StringElementHandler.java ! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java ! src/share/classes/com/sun/beans/decoder/VarElementHandler.java ! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java ! src/share/classes/com/sun/beans/finder/Signature.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayReference.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/BooleanType.java ! src/share/classes/com/sun/jdi/BooleanValue.java ! src/share/classes/com/sun/jdi/Bootstrap.java ! src/share/classes/com/sun/jdi/ByteType.java ! src/share/classes/com/sun/jdi/ByteValue.java ! src/share/classes/com/sun/jdi/CharType.java ! src/share/classes/com/sun/jdi/CharValue.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassObjectReference.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/DoubleType.java ! src/share/classes/com/sun/jdi/DoubleValue.java ! src/share/classes/com/sun/jdi/Field.java ! src/share/classes/com/sun/jdi/FloatType.java ! src/share/classes/com/sun/jdi/FloatValue.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/IntegerType.java ! src/share/classes/com/sun/jdi/IntegerValue.java ! src/share/classes/com/sun/jdi/InterfaceType.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Locatable.java ! src/share/classes/com/sun/jdi/Location.java ! src/share/classes/com/sun/jdi/LongType.java ! src/share/classes/com/sun/jdi/LongValue.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/Mirror.java ! src/share/classes/com/sun/jdi/MonitorInfo.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java ! src/share/classes/com/sun/jdi/PrimitiveType.java ! src/share/classes/com/sun/jdi/PrimitiveValue.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/ShortType.java ! src/share/classes/com/sun/jdi/ShortValue.java ! src/share/classes/com/sun/jdi/StackFrame.java ! src/share/classes/com/sun/jdi/StringReference.java ! src/share/classes/com/sun/jdi/ThreadGroupReference.java ! src/share/classes/com/sun/jdi/ThreadReference.java ! src/share/classes/com/sun/jdi/Type.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/Value.java ! src/share/classes/com/sun/jdi/VirtualMachine.java ! src/share/classes/com/sun/jdi/VirtualMachineManager.java ! src/share/classes/com/sun/jdi/VoidType.java ! src/share/classes/com/sun/jdi/VoidValue.java ! src/share/classes/com/sun/jdi/connect/AttachingConnector.java ! src/share/classes/com/sun/jdi/connect/Connector.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/Transport.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/connect/spi/Connection.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/BreakpointEvent.java ! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java ! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java ! src/share/classes/com/sun/jdi/event/Event.java ! src/share/classes/com/sun/jdi/event/EventIterator.java ! src/share/classes/com/sun/jdi/event/EventQueue.java ! src/share/classes/com/sun/jdi/event/EventSet.java ! src/share/classes/com/sun/jdi/event/ExceptionEvent.java ! src/share/classes/com/sun/jdi/event/LocatableEvent.java ! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java ! src/share/classes/com/sun/jdi/event/MethodExitEvent.java ! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java ! src/share/classes/com/sun/jdi/event/StepEvent.java ! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java ! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java ! src/share/classes/com/sun/jdi/event/VMDeathEvent.java ! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java ! src/share/classes/com/sun/jdi/event/VMStartEvent.java ! src/share/classes/com/sun/jdi/event/WatchpointEvent.java ! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/BreakpointRequest.java ! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java ! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/EventRequest.java ! src/share/classes/com/sun/jdi/request/EventRequestManager.java ! src/share/classes/com/sun/jdi/request/ExceptionRequest.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java ! src/share/classes/com/sun/jdi/request/MethodExitRequest.java ! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java ! src/share/classes/com/sun/jdi/request/StepRequest.java ! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java ! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java ! src/share/classes/com/sun/jdi/request/VMDeathRequest.java ! src/share/classes/com/sun/jdi/request/WatchpointRequest.java ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java ! src/share/classes/com/sun/jndi/ldap/BerDecoder.java ! src/share/classes/com/sun/jndi/ldap/BerEncoder.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/Filter.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java ! src/share/classes/com/sun/management/GarbageCollectorMXBean.java ! src/share/classes/com/sun/management/GcInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java ! src/share/classes/com/sun/media/sound/FastSysexMessage.java ! src/share/classes/com/sun/media/sound/SunFileReader.java ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/com/sun/net/httpserver/Authenticator.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpContext.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/httpserver/HttpHandler.java ! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java ! src/share/classes/com/sun/net/httpserver/HttpServer.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsExchange.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/net/httpserver/HttpsServer.java ! src/share/classes/com/sun/net/httpserver/package-info.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/httpserver/spi/package-info.java ! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java ! src/share/classes/com/sun/nio/sctp/Association.java ! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java ! src/share/classes/com/sun/nio/sctp/HandlerResult.java ! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java ! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java ! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/Notification.java ! src/share/classes/com/sun/nio/sctp/NotificationHandler.java ! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/nio/sctp/SendFailedNotification.java ! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java ! src/share/classes/com/sun/nio/sctp/package-info.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/package.html ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTNumericCredential.java ! src/share/classes/com/sun/security/auth/NTSid.java ! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java ! src/share/classes/com/sun/security/auth/NTUserPrincipal.java ! src/share/classes/com/sun/security/auth/PrincipalComparator.java ! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/UnixPrincipal.java ! src/share/classes/com/sun/security/auth/UserPrincipal.java ! src/share/classes/com/sun/security/auth/X500Principal.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java ! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/com/sun/security/jgss/GSSUtil.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/jgss/InquireType.java ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/tools/attach/AgentInitializationException.java ! src/share/classes/com/sun/tools/attach/AgentLoadException.java ! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java ! src/share/classes/com/sun/tools/attach/AttachPermission.java ! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java ! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html ! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java ! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/SDE.java ! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java ! src/share/classes/com/sun/tools/jdi/ThreadListener.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/script/shell/messages.properties ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/applet/AppletStub.java ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/AWTPermission.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/BufferCapabilities.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/CheckboxGroup.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/EventFilter.java ! src/share/classes/java/awt/FlowLayout.java ! src/share/classes/java/awt/FocusTraversalPolicy.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/FontMetrics.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/Graphics.java ! src/share/classes/java/awt/Graphics2D.java ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/ImageCapabilities.java ! src/share/classes/java/awt/Insets.java ! src/share/classes/java/awt/JobAttributes.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Label.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/LinearGradientPaintContext.java ! src/share/classes/java/awt/MediaTracker.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/MultipleGradientPaintContext.java ! src/share/classes/java/awt/PageAttributes.java ! src/share/classes/java/awt/Polygon.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/Rectangle.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/Shape.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/TrayIcon.java ! src/share/classes/java/awt/WaitDispatchSupport.java ! src/share/classes/java/awt/color/ICC_ColorSpace.java ! src/share/classes/java/awt/color/ICC_ProfileGray.java ! src/share/classes/java/awt/color/ICC_ProfileRGB.java ! src/share/classes/java/awt/color/package.html ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/FlavorMap.java ! src/share/classes/java/awt/datatransfer/MimeType.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/java/awt/datatransfer/Transferable.java ! src/share/classes/java/awt/datatransfer/package.html ! src/share/classes/java/awt/dnd/DnDEventMulticaster.java ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DragGestureListener.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/share/classes/java/awt/dnd/DropTargetDropEvent.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/dnd/package.html ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/doc-files/FocusSpec.html ! src/share/classes/java/awt/doc-files/Modality.html ! src/share/classes/java/awt/event/ActionListener.java ! src/share/classes/java/awt/event/ComponentAdapter.java ! src/share/classes/java/awt/event/ComponentListener.java ! src/share/classes/java/awt/event/ContainerAdapter.java ! src/share/classes/java/awt/event/ContainerEvent.java ! src/share/classes/java/awt/event/ContainerListener.java ! src/share/classes/java/awt/event/FocusAdapter.java ! src/share/classes/java/awt/event/FocusListener.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/InvocationEvent.java ! src/share/classes/java/awt/event/ItemEvent.java ! src/share/classes/java/awt/event/ItemListener.java ! src/share/classes/java/awt/event/KeyAdapter.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/event/MouseAdapter.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/event/MouseListener.java ! src/share/classes/java/awt/event/MouseMotionAdapter.java ! src/share/classes/java/awt/event/MouseMotionListener.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/event/WindowAdapter.java ! src/share/classes/java/awt/event/WindowFocusListener.java ! src/share/classes/java/awt/event/WindowListener.java ! src/share/classes/java/awt/event/package.html ! src/share/classes/java/awt/font/FontRenderContext.java ! src/share/classes/java/awt/font/GlyphMetrics.java ! src/share/classes/java/awt/font/GlyphVector.java ! src/share/classes/java/awt/font/LineBreakMeasurer.java ! src/share/classes/java/awt/font/MultipleMaster.java ! src/share/classes/java/awt/font/NumericShaper.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/font/StyledParagraph.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TextLine.java ! src/share/classes/java/awt/font/TextMeasurer.java ! src/share/classes/java/awt/font/TransformAttribute.java ! src/share/classes/java/awt/font/package.html ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Arc2D.java ! src/share/classes/java/awt/geom/Dimension2D.java ! src/share/classes/java/awt/geom/FlatteningPathIterator.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/java/awt/geom/Point2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/geom/RectangularShape.java ! src/share/classes/java/awt/geom/package.html ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/java/awt/im/InputMethodHighlight.java ! src/share/classes/java/awt/im/InputMethodRequests.java ! src/share/classes/java/awt/image/BandedSampleModel.java ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ByteLookupTable.java ! src/share/classes/java/awt/image/ColorConvertOp.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/awt/image/ComponentColorModel.java ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/java/awt/image/ImageFilter.java ! src/share/classes/java/awt/image/ImageProducer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/Kernel.java ! src/share/classes/java/awt/image/MemoryImageSource.java ! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java ! src/share/classes/java/awt/image/PixelGrabber.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/RGBImageFilter.java ! src/share/classes/java/awt/image/Raster.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/java/awt/image/ShortLookupTable.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/classes/java/awt/image/WritableRaster.java ! src/share/classes/java/awt/image/package.html ! src/share/classes/java/awt/image/renderable/RenderableImage.java ! src/share/classes/java/awt/image/renderable/RenderableImageOp.java ! src/share/classes/java/awt/image/renderable/package.html ! src/share/classes/java/awt/package.html ! src/share/classes/java/awt/peer/CheckboxPeer.java ! src/share/classes/java/awt/peer/DesktopPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/print/Book.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/java/awt/print/package.html ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/NameGenerator.java ! src/share/classes/java/beans/PropertyEditorManager.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/SimpleBeanInfo.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/ByteArrayInputStream.java ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DataOutput.java ! src/share/classes/java/io/EOFException.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/FileSystem.java ! src/share/classes/java/io/ObjectStreamConstants.java ! src/share/classes/java/io/PipedReader.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/io/Serializable.java ! src/share/classes/java/io/SerializablePermission.java ! src/share/classes/java/io/StringReader.java ! src/share/classes/java/lang/ArrayStoreException.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassCastException.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/java/lang/instrument/package.html ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/Stable.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/ReflectPermission.java ! src/share/classes/java/lang/reflect/Type.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/SocketAddress.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template ! src/share/classes/java/nio/ByteOrder.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/Heap-X-Buffer.java.template ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channel.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/Pipe.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/Selector.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectionKey.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/nio/charset/CodingErrorAction.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/package.html ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/sql/Array.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DataTruncation.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverPropertyInfo.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java ! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java ! src/share/classes/java/sql/SQLNonTransientConnectionException.java ! src/share/classes/java/sql/SQLNonTransientException.java ! src/share/classes/java/sql/SQLRecoverableException.java ! src/share/classes/java/sql/SQLSyntaxErrorException.java ! src/share/classes/java/sql/SQLTransactionRollbackException.java ! src/share/classes/java/sql/SQLTransientConnectionException.java ! src/share/classes/java/sql/SQLTransientException.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/Struct.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/java/text/CharacterIterator.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/ArraysParallelSortHelpers.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ConcurrentModificationException.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/DualPivotQuicksort.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formattable.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/java/util/MissingFormatWidthException.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimerTask.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/package-info.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/regex/UnicodeProp.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/DeflaterInputStream.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPOutputStream.java ! src/share/classes/java/util/zip/InflaterInputStream.java ! src/share/classes/java/util/zip/InflaterOutputStream.java ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipConstants64.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/javax/accessibility/AccessibleAction.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/accessibility/AccessibleText.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/crypto/spec/IvParameterSpec.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ! src/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/share/classes/javax/imageio/IIOParam.java ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReadParam.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageTypeSpecifier.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/event/IIOReadProgressListener.java ! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java ! src/share/classes/javax/imageio/event/IIOReadWarningListener.java ! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java ! src/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java ! src/share/classes/javax/imageio/spi/IIORegistry.java ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/share/classes/javax/imageio/spi/ImageWriterSpi.java ! src/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/share/classes/javax/imageio/stream/ImageOutputStream.java ! src/share/classes/javax/management/AttributeList.java ! src/share/classes/javax/management/BadAttributeValueExpException.java ! src/share/classes/javax/management/BooleanValueExp.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/DescriptorKey.java ! src/share/classes/javax/management/ImmutableDescriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MBeanServerFactory.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/MBeanTrustPermission.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/NumericValueExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/PersistentMBean.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/StandardEmitterMBean.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetParser.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/monitor/package.html ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/package.html ! src/share/classes/javax/management/relation/Relation.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/remote/JMXConnectionNotification.java ! src/share/classes/javax/management/remote/JMXConnector.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorProvider.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/JMXPrincipal.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/share/classes/javax/management/remote/rmi/package.html ! src/share/classes/javax/naming/BinaryRefAddr.java ! src/share/classes/javax/naming/Binding.java ! src/share/classes/javax/naming/InsufficientResourcesException.java ! src/share/classes/javax/naming/directory/Attribute.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/PagedResultsControl.java ! src/share/classes/javax/naming/ldap/SortControl.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/SSLContextSpi.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSession.java ! src/share/classes/javax/net/ssl/SSLSessionContext.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/print/CancelablePrintJob.java ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/MultiDocPrintJob.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/ServiceUI.java ! src/share/classes/javax/print/ServiceUIFactory.java ! src/share/classes/javax/print/attribute/AttributeSet.java ! src/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/share/classes/javax/print/attribute/DocAttributeSet.java ! src/share/classes/javax/print/attribute/EnumSyntax.java ! src/share/classes/javax/print/attribute/HashAttributeSet.java ! src/share/classes/javax/print/attribute/IntegerSyntax.java ! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/share/classes/javax/print/attribute/Size2DSyntax.java ! src/share/classes/javax/print/attribute/package.html ! src/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/share/classes/javax/print/attribute/standard/Compression.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MediaSize.java ! src/share/classes/javax/print/attribute/standard/MediaTray.java ! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/Sides.java ! src/share/classes/javax/print/attribute/standard/package.html ! src/share/classes/javax/print/event/package.html ! src/share/classes/javax/print/package.html ! src/share/classes/javax/script/AbstractScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java ! src/share/classes/javax/script/ScriptEngine.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/smartcardio/CardChannel.java ! src/share/classes/javax/smartcardio/CardTerminal.java ! src/share/classes/javax/smartcardio/ResponseAPDU.java ! src/share/classes/javax/sound/midi/Soundbank.java ! src/share/classes/javax/sound/sampled/DataLine.java ! src/share/classes/javax/sound/sampled/ReverbType.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java ! src/share/classes/javax/sql/rowset/spi/XmlReader.java ! src/share/classes/javax/sql/rowset/spi/XmlWriter.java ! src/share/classes/javax/swing/AbstractAction.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/BoundedRangeModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/ClientPropertyKey.java ! src/share/classes/javax/swing/ComboBoxModel.java ! src/share/classes/javax/swing/ComponentInputMap.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultCellEditor.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/DefaultListCellRenderer.java ! src/share/classes/javax/swing/DefaultListModel.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultRowSorter.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/DesktopManager.java ! src/share/classes/javax/swing/FocusManager.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/InputVerifier.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/MenuSelectionManager.java ! src/share/classes/javax/swing/MutableComboBoxModel.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/Painter.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/PopupFactory.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/ProgressMonitorInputStream.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/RootPaneContainer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/ScrollPaneConstants.java ! src/share/classes/javax/swing/ScrollPaneLayout.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/WindowConstants.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/BevelBorder.java ! src/share/classes/javax/swing/border/Border.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/EtchedBorder.java ! src/share/classes/javax/swing/border/LineBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/SoftBevelBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/border/package.html ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java ! src/share/classes/javax/swing/colorchooser/package.html ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/ListSelectionEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeExpansionListener.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeModelListener.java ! src/share/classes/javax/swing/event/TreeSelectionEvent.java ! src/share/classes/javax/swing/event/TreeSelectionListener.java ! src/share/classes/javax/swing/event/TreeWillExpandListener.java ! src/share/classes/javax/swing/event/UndoableEditEvent.java ! src/share/classes/javax/swing/event/package.html ! src/share/classes/javax/swing/filechooser/FileFilter.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/filechooser/package.html ! src/share/classes/javax/swing/package.html ! src/share/classes/javax/swing/plaf/BorderUIResource.java ! src/share/classes/javax/swing/plaf/ColorUIResource.java ! src/share/classes/javax/swing/plaf/ComboBoxUI.java ! src/share/classes/javax/swing/plaf/ComponentUI.java ! src/share/classes/javax/swing/plaf/DimensionUIResource.java ! src/share/classes/javax/swing/plaf/FontUIResource.java ! src/share/classes/javax/swing/plaf/IconUIResource.java ! src/share/classes/javax/swing/plaf/InsetsUIResource.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/basic/package.html ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/plaf/metal/package.html ! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java ! src/share/classes/javax/swing/plaf/multi/package.html ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/nimbus/package.html ! src/share/classes/javax/swing/plaf/package.html ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboPopup.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPainter.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java ! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableCellRenderer.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/table/TableColumnModel.java ! src/share/classes/javax/swing/table/TableModel.java ! src/share/classes/javax/swing/table/package.html ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/Caret.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/DateFormatter.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultFormatterFactory.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/EditorKit.java ! src/share/classes/javax/swing/text/Element.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/FieldView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GapVector.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NavigationFilter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/PasswordView.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/PlainView.java ! src/share/classes/javax/swing/text/Position.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledDocument.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabExpander.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/TabStop.java ! src/share/classes/javax/swing/text/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/CSSParser.java ! src/share/classes/javax/swing/text/html/FormSubmitEvent.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/FrameSetView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/InlineView.java ! src/share/classes/javax/swing/text/html/ObjectView.java ! src/share/classes/javax/swing/text/html/Option.java ! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/package.html ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/package.html ! src/share/classes/javax/swing/text/package.html ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/javax/swing/text/rtf/package.html ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/ExpandVetoException.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeNode.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/tree/package.html ! src/share/classes/javax/swing/undo/CannotRedoException.java ! src/share/classes/javax/swing/undo/CannotUndoException.java ! src/share/classes/javax/swing/undo/UndoManager.java ! src/share/classes/javax/swing/undo/package.html ! src/share/classes/javax/xml/crypto/KeySelector.java ! src/share/classes/javax/xml/crypto/MarshalException.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/TransformException.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java ! 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/XMLStreamException.java ! src/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/share/classes/org/ietf/jgss/GSSContext.java ! src/share/classes/org/ietf/jgss/GSSCredential.java ! src/share/classes/org/ietf/jgss/GSSException.java ! src/share/classes/org/ietf/jgss/GSSManager.java ! src/share/classes/org/ietf/jgss/GSSName.java ! src/share/classes/org/ietf/jgss/package.html ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/sun/applet/AppletClassLoader.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/applet/AppletViewer.java ! src/share/classes/sun/applet/Main.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/CausedFocusEvent.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/EventListenerAggregate.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/FontDescriptor.java ! src/share/classes/sun/awt/HToolkit.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerProvider.java ! src/share/classes/sun/awt/ModalityEvent.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/share/classes/sun/awt/PaintEventDispatcher.java ! src/share/classes/sun/awt/PeerEvent.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java ! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java ! src/share/classes/sun/awt/datatransfer/TransferableProxy.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodContext.java ! src/share/classes/sun/awt/im/InputMethodJFrame.java ! src/share/classes/sun/awt/im/InputMethodManager.java ! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java ! src/share/classes/sun/awt/image/ByteBandedRaster.java ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/BytePackedRaster.java ! src/share/classes/sun/awt/image/ImageRepresentation.java ! src/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/awt/image/ShortBandedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/classes/sun/awt/image/SurfaceManager.java ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CreatedFontTracker.java ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/font/FontManagerForSGE.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/GlyphList.java ! src/share/classes/sun/font/LayoutPathImpl.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StandardTextSource.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TextLabelFactory.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/invoke/WrapperInstance.java ! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/cmm/CMSManager.java ! src/share/classes/sun/java2d/cmm/PCMM.java ! 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/classes/sun/java2d/loops/Blit.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/loops/ProcessPath.java ! src/share/classes/sun/java2d/loops/SurfaceType.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLDrawImage.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLRenderQueue.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/GlyphListPipe.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java ! src/share/classes/sun/java2d/pipe/Region.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/AgentConfigurationError.java ! src/share/classes/sun/management/BaseOperatingSystemImpl.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/counter/perf/InstrumentationException.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/misc/CRC16.java ! src/share/classes/sun/misc/CharacterDecoder.java ! src/share/classes/sun/misc/ClassFileTransformer.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/PerfCounter.java ! src/share/classes/sun/misc/PerformanceLogger.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/misc/Version.java.template ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/TelnetOutputStream.java ! src/share/classes/sun/net/ftp/FtpClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/smtp/SmtpProtocolException.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeDispatcher.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/ThreadPool.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java ! src/share/classes/sun/nio/fs/Util.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/print/PrintJob2D.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java ! src/share/classes/sun/reflect/generics/repository/ClassRepository.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/rmi/rmic/RemoteClass.java ! src/share/classes/sun/rmi/rmic/Util.java ! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/security/ec/CurveDB.java ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/NamedCurve.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/krb5/internal/rcache/AuthList.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/Krb5Proxy.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java ! src/share/classes/sun/security/util/ECKeySizeParameterSpec.java ! src/share/classes/sun/security/util/ECUtil.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/URIName.java ! src/share/classes/sun/swing/DefaultLayoutStyle.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/PrintingStatus.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/swing/text/TextComponentPrintable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/classes/sun/text/resources/th/CollationData_th.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/tools/jar/JarException.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/classes/sun/tools/jar/resources/jar.properties ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/java/BinaryConstantPool.java ! src/share/classes/sun/tools/java/ClassDeclaration.java ! src/share/classes/sun/tools/java/MemberDefinition.java ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/jstat/ColumnFormat.java ! src/share/classes/sun/tools/jstat/RowClosure.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/tools/serialver/SerialVer.java ! src/share/classes/sun/tools/tree/ExprExpression.java ! src/share/classes/sun/tools/tree/FieldExpression.java ! src/share/classes/sun/tracing/ProviderSkeleton.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/resources/logging.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/Destinations.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Group.java ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Modifier.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Node.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ResultSet.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Test.java ! src/share/demo/java2d/J2DBench/src/j2dbench/TestEnvironment.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/IIOComparator.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/MiscTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/RenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextConstructionTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextMeasureTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextRenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/CompactLayout.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/EnableButton.java ! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java ! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/javavm/export/jawt.h ! src/share/lib/calendars.properties ! src/share/native/com/sun/media/sound/DirectAudioDevice.c ! src/share/native/com/sun/media/sound/Platform.c ! src/share/native/com/sun/media/sound/PlatformMidi.h ! src/share/native/com/sun/media/sound/SoundDefs.h ! src/share/native/com/sun/media/sound/Utilities.h ! src/share/native/java/lang/SecurityManager.c ! src/share/native/java/lang/System.c ! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c ! src/share/native/java/lang/java_props.h ! src/share/native/java/net/Inet4Address.c ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/InetAddress.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/share/native/sun/awt/debug/debug_assert.h ! src/share/native/sun/awt/debug/debug_mem.c ! src/share/native/sun/awt/debug/debug_trace.h ! src/share/native/sun/awt/debug/debug_util.h ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/share/native/sun/awt/image/DataBufferNative.c ! src/share/native/sun/awt/image/awt_ImageRep.c ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/image/cvutils/img_dcm.h ! src/share/native/sun/awt/image/cvutils/img_dcm8.h ! src/share/native/sun/awt/image/cvutils/img_globals.c ! src/share/native/sun/awt/image/cvutils/img_replscale.h ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageAffine.c ! src/share/native/sun/awt/medialib/mlib_ImageAffine.h ! src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c ! src/share/native/sun/awt/medialib/mlib_ImageColorTrue2Index.c ! src/share/native/sun/awt/medialib/mlib_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN.c ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_D64nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_F32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageCopy_Bit.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_image.h ! src/share/native/sun/awt/medialib/mlib_sys.c ! src/share/native/sun/awt/medialib/mlib_types.h ! src/share/native/sun/awt/medialib/safe_alloc.h ! src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/share/native/sun/awt/splashscreen/splashscreen_impl.h ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/DrawGlyphList.c ! src/share/native/sun/font/FontInstanceAdapter.cpp ! src/share/native/sun/font/FontInstanceAdapter.h ! src/share/native/sun/font/fontscalerdefs.h ! src/share/native/sun/font/freetypeScaler.c ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/share/native/sun/java2d/Disposer.c ! src/share/native/sun/java2d/SurfaceData.c ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/loops/AnyByteBinary.h ! src/share/native/sun/java2d/loops/Blit.c ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/ByteIndexed.h ! src/share/native/sun/java2d/loops/DrawPath.c ! src/share/native/sun/java2d/loops/DrawPolygons.c ! src/share/native/sun/java2d/loops/FillPath.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/MaskBlit.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/loops/ScaledBlit.c ! src/share/native/sun/java2d/loops/TransformHelper.c ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/UshortIndexed.h ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLFuncs.h ! src/share/native/sun/java2d/opengl/OGLRenderQueue.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.h ! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c ! src/share/native/sun/java2d/pipe/Region.c ! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c ! src/share/native/sun/java2d/pipe/SpanClipRenderer.c ! src/share/native/sun/management/HotSpotDiagnostic.c ! src/share/native/sun/reflect/Reflection.c ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/share/native/sun/security/jgss/wrapper/gssapi.h ! src/share/native/sun/security/krb5/nativeccache.c ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/npt/npt.h ! src/share/npt/utf.c ! src/share/sample/jmx/jmx-scandir/index.html ! src/share/sample/scripting/scriptpad/src/scripts/memory.sh ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/back/linker_md.c ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeerListener.java ! src/solaris/classes/sun/awt/X11/XClipboard.java ! src/solaris/classes/sun/awt/X11/XDataTransferer.java ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/classes/sun/awt/X11/XDialogPeer.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XPanelPeer.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XRepaintArea.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/font/XMap.java ! src/solaris/classes/sun/font/XRGlyphCacheEntry.java ! src/solaris/classes/sun/font/XRTextRenderer.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java ! src/solaris/classes/sun/java2d/jules/TileTrapContainer.java ! src/solaris/classes/sun/java2d/x11/X11Renderer.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java ! src/solaris/classes/sun/java2d/xr/MaskTile.java ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java ! src/solaris/classes/sun/java2d/xr/XRBackend.java ! src/solaris/classes/sun/java2d/xr/XRBackendNative.java ! src/solaris/classes/sun/java2d/xr/XRColor.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java ! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java ! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java ! src/solaris/classes/sun/java2d/xr/XRPaints.java ! src/solaris/classes/sun/java2d/xr/XRRenderer.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java ! src/solaris/classes/sun/management/OperatingSystemImpl.java ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/KQueue.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixMountEntry.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java ! src/solaris/classes/sun/print/AttributeClass.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/javavm/export/jni_md.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiIn.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiOut.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h ! src/solaris/native/com/sun/security/auth/module/Solaris.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/awt/CUPSfuncs.c ! src/solaris/native/sun/awt/VDrawingArea.c ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_AWTEvent.c ! src/solaris/native/sun/awt/awt_Component.h ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/awt/awt_Font.h ! src/solaris/native/sun/awt/awt_LoadLibrary.c ! src/solaris/native/sun/awt/awt_Mlib.c ! src/solaris/native/sun/awt/awt_Mlib.h ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/awt_p.h ! src/solaris/native/sun/awt/canvas.h ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/awt/initIDs.c ! src/solaris/native/sun/awt/jawt.c ! src/solaris/native/sun/awt/multiVis.c ! src/solaris/native/sun/awt/multi_font.c ! src/solaris/native/sun/awt/multi_font.h ! src/solaris/native/sun/awt/robot_common.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c ! src/solaris/native/sun/awt/swing_GTKEngine.c ! src/solaris/native/sun/font/X11FontScaler.c ! src/solaris/native/sun/font/X11TextRenderer.c ! src/solaris/native/sun/java2d/j2d_md.h ! src/solaris/native/sun/java2d/loops/mlib_ImageZoom_NN.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h ! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h ! src/solaris/native/sun/java2d/x11/X11Renderer.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c ! src/solaris/native/sun/management/LinuxOperatingSystem.c ! src/solaris/native/sun/management/MacosxOperatingSystem.c ! src/solaris/native/sun/management/OperatingSystemImpl.c ! src/solaris/native/sun/management/SolarisOperatingSystem.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/solaris/native/sun/xawt/XWindow.c ! src/solaris/transport/socket/socket_md.c ! src/windows/back/linker_md.c ! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java ! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/DualStackPlainSocketImpl.java ! src/windows/classes/java/net/PlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WBufferStrategy.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WClipboard.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WDialogPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java ! src/windows/classes/sun/awt/windows/WPageDialog.java ! src/windows/classes/sun/awt/windows/WPageDialogPeer.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialog.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/classes/sun/java2d/ScreenUpdateManager.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/windows/classes/sun/java2d/windows/GDIRenderer.java ! src/windows/classes/sun/management/OperatingSystemImpl.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/nio/ch/DatagramDispatcher.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/FileKey.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsSecurity.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/classes/sun/print/Win32MediaTray.java ! src/windows/classes/sun/print/Win32PrintJob.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c ! src/windows/native/java/io/Console_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/SocketInputStream.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/icmp.h ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/font/lcdglyph.c ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h ! src/windows/native/sun/java2d/d3d/D3DPipeline.h ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/management/OperatingSystemImpl.c ! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/windows/CmdIDList.cpp ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ObjectList.cpp ! src/windows/native/sun/windows/ObjectList.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/alloc.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h ! src/windows/native/sun/windows/awt_Clipboard.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_List.h ! src/windows/native/sun/windows/awt_Menu.cpp ! src/windows/native/sun/windows/awt_Menu.h ! src/windows/native/sun/windows/awt_MenuBar.cpp ! src/windows/native/sun/windows/awt_MenuBar.h ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_MenuItem.h ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_Mlib.h ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Object.h ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PopupMenu.h ! src/windows/native/sun/windows/awt_PrintControl.h ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_TextField.h ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Window.h ! src/windows/native/sun/windows/awt_ole.cpp ! src/windows/native/sun/windows/awtmsg.h ! src/windows/native/sun/windows/stdhdrs.h ! src/windows/transport/socket/socket_md.c ! test/com/oracle/net/sanity.sh ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/JDIScaffold.java ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/NativeInstanceFilter.java ! test/com/sun/jdi/NoLaunchOptionTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/TestScaffold.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java ! test/com/sun/jndi/cosnaming/CNNameParser.java ! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java ! test/com/sun/tools/attach/Application.java ! test/com/sun/tools/attach/RedefineAgent.java ! test/com/sun/tools/extcheck/TestExtcheckArgs.sh ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh ! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java ! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html ! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java ! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html ! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html ! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html ! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java ! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html ! test/java/awt/FileDialog/MultipleMode/MultipleMode.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java ! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html ! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java ! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html ! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html ! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java ! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html ! test/java/awt/FontMetrics/StyledSpaceAdvance.java ! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java ! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html ! test/java/awt/Frame/ShownOnPack/ShownOnPack.html ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java ! test/java/awt/Graphics/LineClipTest.java ! test/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java ! test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java ! test/java/awt/GraphicsDevice/CloneConfigsTest.java ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html ! test/java/awt/List/SetFontTest/SetFontTest.html ! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java ! test/java/awt/Menu/OpensWithNoGrab/OpensWithNoGrab.java ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java ! test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java ! test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java ! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html ! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java ! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java ! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html ! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java ! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html ! test/java/awt/PrintJob/Text/stringwidth.sh ! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java ! test/java/awt/Robot/ManualInstructions/ManualInstructions.java ! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java ! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java ! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html ! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html ! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html ! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java ! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java ! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java ! test/java/awt/Window/Grab/GrabTest.java ! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java ! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java ! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html ! test/java/awt/dnd/Button2DragTest/Button2DragTest.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java ! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html ! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java ! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html ! test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java ! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java ! test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java ! test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java ! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html ! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html ! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java ! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java ! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html ! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html ! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java ! test/java/awt/im/4490692/bug4490692.html ! test/java/awt/im/4959409/bug4959409.html ! test/java/awt/im/JTextFieldTest.html ! test/java/awt/image/BufferedImage/TinyScale.java ! test/java/awt/image/GetSamplesTest.java ! test/java/awt/image/IncorrectSampleMaskTest.java ! test/java/awt/image/mlib/MlibOpsTest.java ! test/java/awt/print/PageFormat/PageFormatFromAttributes.java ! test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java ! test/java/awt/print/PrinterJob/Collate2DPrintingTest.java ! test/java/awt/print/PrinterJob/PrintGlyphVectorTest.java ! test/java/awt/regtesthelpers/Util.java ! test/java/beans/Beans/6669869/TestDesignTime.java ! test/java/beans/Beans/6669869/TestGuiAvailable.java ! test/java/beans/EventHandler/Test6277266.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java ! test/java/beans/Introspector/6380849/beans/FirstBean.java ! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java ! test/java/beans/Introspector/6380849/beans/SecondBean.java ! test/java/beans/Introspector/6380849/beans/ThirdBean.java ! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java ! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java ! test/java/beans/Introspector/6976577/test/Accessor.java ! test/java/beans/Introspector/7122138/pack/Sub.java ! test/java/beans/Introspector/7122138/pack/Super.java ! test/java/beans/Introspector/Test4683761.java ! test/java/beans/Introspector/Test6660539.java ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/java/beans/XMLEncoder/6380849/Bean.java ! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java ! test/java/beans/XMLEncoder/AbstractTest.java ! test/java/beans/XMLEncoder/BeanValidator.java ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4679556.java ! test/java/beans/XMLEncoder/java_awt_BorderLayout.java ! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java ! test/java/io/File/GetXSpace.sh ! test/java/io/FileInputStream/OpsAfterClose.java ! test/java/io/FileOutputStream/OpsAfterClose.java ! test/java/io/RandomAccessFile/OpsAfterClose.java ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/AddedExternField/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/io/Serializable/subclass/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/CharSequence/DefaultTest.java ! test/java/lang/Class/forName/NonJavaNames.sh ! test/java/lang/Class/getEnclosingClass/build.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/getdotresource.sh ! test/java/lang/Double/ParseDouble.java ! test/java/lang/Float/ParseFloat.java ! test/java/lang/IntegralPrimitiveToString.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/ExactArithTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/PrimitiveSumMinMaxTest.java ! test/java/lang/String/Split.java ! test/java/lang/String/ToLowerCase.java ! test/java/lang/StringBuffer/BufferForwarding.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/StringBuilder/BuilderForwarding.java ! test/java/lang/StringBuilder/Supplementary.java ! test/java/lang/System/MacEncoding/ExpectedEncoding.java ! test/java/lang/Thread/GenerifyStackTraces.java ! test/java/lang/Thread/ThreadStateTest.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/invoke/lambda/LUtils.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/RuntimeMXBean/UpTime.java ! test/java/lang/management/ThreadMXBean/LockedMonitors.java ! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java ! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java ! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java ! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java ! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java ! test/java/lang/ref/ReferenceEnqueuePending.java ! test/java/lang/reflect/Array/ExceedMaxDim.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Method/IsDefaultTest.java ! test/java/lang/reflect/Proxy/Basic1.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/math/BigDecimal/CompareToTests.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/IntegralDivisionTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/math/BigInteger/CompareToTests.java ! test/java/math/BigInteger/DivisionOverflow.java ! test/java/math/BigInteger/ExtremeShiftingTests.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/BindException/Test.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InterfaceAddress/NetworkPrefixLength.java ! test/java/net/MulticastSocket/TestInterfaces.java ! test/java/net/NetworkInterface/Equals.java ! test/java/net/NetworkInterface/IndexTest.java ! test/java/net/NetworkInterface/Test.java ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh ! test/java/net/Socket/LingerTest.java ! test/java/net/Socks/SocksProxyVersion.java ! test/java/net/URI/Test.java ! test/java/net/URL/HandlerLoop.java ! test/java/net/URL/Test.java ! test/java/net/URL/URIToURLTest.java ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/closetest/Common.java ! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLConnection/RequestPropertyValues.java ! test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor ! test/java/net/URLPermission/nstest/SimpleNameService.java ! test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/BadIPv6Addresses.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/ConnectedSend.java ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java ! test/java/nio/channels/Pipe/PipeInterrupt.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java ! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java ! test/java/nio/channels/SocketChannel/ShortWrite.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java ! test/java/nio/file/Files/CheckPermissions.java ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/walkFileTree/CreateFileTree.java ! test/java/nio/file/Files/walkFileTree/MaxDepth.java ! test/java/nio/file/Files/walkFileTree/SkipSiblings.java ! test/java/nio/file/Files/walkFileTree/TerminateWalk.java ! test/java/nio/file/Files/walkFileTree/find.sh ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/rmi/MarshalledObject/compare/Compare.java ! test/java/rmi/MarshalledObject/compare/HashCode.java ! test/java/rmi/MarshalledObject/compare/NullReference.java ! test/java/rmi/Naming/DefaultRegistryPort.java ! test/java/rmi/Naming/LookupIPv6.java ! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/CommandEnvironment/NullOptions.java ! test/java/rmi/activation/log/LogTest.java ! test/java/rmi/dgc/VMID/CheckVMID.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java ! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java ! test/java/rmi/invalidName/InvalidName.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java ! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java ! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java ! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java ! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java ! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Installed.java ! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Property.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java ! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java ! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java ! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java ! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java ! test/java/rmi/server/Unmarshal/PrimitiveClasses.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java ! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java ! test/java/rmi/server/clientStackTrace/ClientStackTrace.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/rmi/server/serverStackTrace/ServerStackTrace.java ! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java ! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java ! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java ! test/java/security/Principal/Implies.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh ! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java ! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh ! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh ! test/java/security/cert/CertStore/NoLDAP.java ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/security/cert/CertificateRevokedException/Basic.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/java/text/Bidi/BidiConformance.java ! test/java/text/Format/DecimalFormat/TieRoundingTest.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/util/TestFormatter.java ! test/java/util/Arrays/ParallelSorting.java ! test/java/util/Base64/TestBase64.java ! test/java/util/Base64/TestBase64Golden.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Calendar/NarrowNamesTest.sh ! test/java/util/Collection/CollectionDefaults.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collection/testlibrary/CollectionAsserts.java ! test/java/util/Collection/testlibrary/CollectionSupplier.java ! test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java ! test/java/util/Collection/testlibrary/ExtendsAbstractList.java ! test/java/util/Collection/testlibrary/ExtendsAbstractSet.java ! test/java/util/Collections/CheckedIdentityMap.java ! test/java/util/Collections/CheckedMapBash.java ! test/java/util/Collections/CheckedSetBash.java ! test/java/util/Collections/EmptyCollectionSerialization.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/Collections/ReverseOrder.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/Basic.sh ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Iterator/IteratorDefaults.java ! test/java/util/LinkedHashMap/Basic.java ! test/java/util/List/ListDefaults.java ! test/java/util/Locale/InternationalBAT.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/Locale/LocaleTestFmwk.java ! test/java/util/Locale/tools/EquivMapsGenerator.java ! test/java/util/Map/BasicSerialization.java ! test/java/util/Map/Collisions.java ! test/java/util/Map/EntryComparators.java ! test/java/util/Map/LockStep.java ! test/java/util/NavigableMap/LockStep.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PriorityQueue/RemoveContains.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh ! test/java/util/ResourceBundle/ResourceBundleTest.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/Bug6912560.java ! test/java/util/TimeZone/CLDRDisplayNamesTest.java ! test/java/util/TimeZone/ListTimeZones.java ! test/java/util/TimeZone/OldIDMappingTest.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/TzIDOldMapping.java ! test/java/util/TreeMap/Clone.java ! test/java/util/concurrent/Executors/PrivilegedCallables.java ! test/java/util/concurrent/FutureTask/Throw.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/atomic/AtomicReferenceTest.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/function/BinaryOperator/BasicTest.java ! test/java/util/jar/TestExtra.java ! test/java/util/logging/CheckLockLocationTest.java ! test/java/util/logging/LoggerSupplierAPIsTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/Reflect.java ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefFirst.java ! test/java/util/prefs/CheckUserPrefLater.java ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java ! test/java/util/regex/POSIX_Unicode.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java ! test/java/util/zip/3GBZipFiles.sh ! test/java/util/zip/LargeZip.java ! test/java/util/zip/StoredCRC.java ! test/java/util/zip/TotalInOut.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/FinalizeZipFile.java ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/plugins/gif/GIFPassListenerTest.java ! test/javax/imageio/plugins/gif/GifTransparencyTest.java ! test/javax/management/MBeanInfo/SerializationTest1.java ! test/javax/management/modelmbean/LoggingExceptionTest.java ! test/javax/management/monitor/CounterMonitorThresholdTest.java ! test/javax/management/monitor/NullAttributeValueTest.java ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.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/connection/RMIConnectionIdTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java ! test/javax/print/DialogMargins.java ! test/javax/print/StreamPrintingOrientation.java ! test/javax/print/applet/AppletPrintLookup.html ! test/javax/print/attribute/autosense/PrintAutoSenseData.java ! test/javax/rmi/ssl/SocketFactoryTest.java ! test/javax/script/CauseExceptionTest.java ! test/javax/script/ExceptionTest.java ! test/javax/script/GetInterfaceTest.java ! test/javax/script/Helper.java ! test/javax/script/ProviderTest.sh ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/Test5.java ! test/javax/script/Test6.java ! test/javax/script/UnescapedBracketRegExTest.java ! test/javax/script/VersionTest.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/javax/sound/midi/File/SMPTESequence.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java ! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java ! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java ! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/Controller.java ! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java ! test/javax/sound/midi/Gervill/SoftChannel/Mono.java ! test/javax/sound/midi/Gervill/SoftChannel/Mute.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java ! test/javax/sound/midi/Gervill/SoftChannel/Omni.java ! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java ! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftChannel/Solo.java ! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java ! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java ! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java ! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Close.java ! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java ! test/javax/sound/midi/Gervill/SoftTuning/GetName.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java ! test/javax/sound/midi/Gervill/SoftTuning/Load1.java ! test/javax/sound/midi/Gervill/SoftTuning/Load2.java ! test/javax/sound/midi/Gervill/SoftTuning/Load4.java ! test/javax/sound/midi/Gervill/SoftTuning/Load5.java ! test/javax/sound/midi/Gervill/SoftTuning/Load6.java ! test/javax/sound/midi/Gervill/SoftTuning/Load7.java ! test/javax/sound/midi/Gervill/SoftTuning/Load8.java ! test/javax/sound/midi/Gervill/SoftTuning/Load9.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java ! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java ! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java ! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java ! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java ! test/javax/sound/sampled/Clip/ClipSetPos.java ! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java ! test/javax/sound/sampled/DirectAudio/bug6400879.java ! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java ! test/javax/sound/sampled/FileWriter/WriterCloseInput.java ! test/javax/swing/JCheckBox/4449413/bug4449413.html ! test/javax/swing/JColorChooser/Test4222508.html ! test/javax/swing/JColorChooser/Test4759306.html ! test/javax/swing/JColorChooser/Test4759934.html ! test/javax/swing/JColorChooser/Test4887836.html ! test/javax/swing/JColorChooser/Test6348456.html ! test/javax/swing/JColorChooser/Test6977726.html ! test/javax/swing/JComboBox/7082443/bug7082443.java ! test/javax/swing/JComponent/4337267/bug4337267.java ! test/javax/swing/JComponent/6683775/bug6683775.java ! test/javax/swing/JEditorPane/4492274/test.html ! test/javax/swing/JEditorPane/6917744/test.html ! test/javax/swing/JEditorPane/bug4714674.java ! test/javax/swing/JFileChooser/6570445/bug6570445.java ! test/javax/swing/JFileChooser/6698013/bug6698013.html ! test/javax/swing/JFileChooser/6698013/bug6698013.java ! test/javax/swing/JFileChooser/6798062/bug6798062.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.java ! test/javax/swing/JList/6462008/bug6462008.java ! test/javax/swing/JPopupMenu/4966112/bug4966112.java ! test/javax/swing/JPopupMenu/6694823/bug6694823.java ! test/javax/swing/JSlider/4987336/bug4987336.html ! test/javax/swing/JSlider/6524424/bug6524424.html ! test/javax/swing/JSlider/6587742/bug6587742.html ! test/javax/swing/JSlider/6742358/bug6742358.html ! test/javax/swing/JSplitPane/4885629/bug4885629.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.html ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/8005019/bug8005019.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/JTree/4314199/bug4314199.html ! test/javax/swing/JTree/4908142/bug4908142.java ! test/javax/swing/JTree/6263446/bug6263446.java ! test/javax/swing/SpringLayout/4726194/bug4726194.java ! test/javax/swing/SwingUtilities/7170657/bug7170657.java ! test/javax/swing/border/Test4129681.html ! test/javax/swing/border/Test4243289.html ! test/javax/swing/border/Test4247606.html ! test/javax/swing/border/Test4252164.html ! test/javax/swing/border/Test4760089.html ! test/javax/swing/border/Test6910490.html ! test/javax/swing/border/Test7022041.java ! test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/javax/swing/text/html/TableView/7030332/bug7030332.html ! test/javax/swing/text/html/parser/Parser/7003777/bug7003777.java ! test/jdk/lambda/ArrayCtorRefTest.java ! test/jdk/lambda/FDTest.java ! test/jdk/lambda/LambdaTranslationCompoundSamTest.java ! test/jdk/lambda/LambdaTranslationInInterface.java ! test/jdk/lambda/LambdaTranslationTest1.java ! test/jdk/lambda/LambdaTranslationTest2.java ! test/jdk/lambda/MethodReferenceTestInnerDefault.java ! test/jdk/lambda/MethodReferenceTestInnerInstance.java ! test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java ! test/jdk/lambda/MethodReferenceTestInstance.java ! test/jdk/lambda/MethodReferenceTestInstanceMethod.java ! test/jdk/lambda/MethodReferenceTestKinds.java ! test/jdk/lambda/MethodReferenceTestNew.java ! test/jdk/lambda/MethodReferenceTestNewInner.java ! test/jdk/lambda/MethodReferenceTestSuper.java ! test/jdk/lambda/MethodReferenceTestSuperDefault.java ! test/jdk/lambda/MethodReferenceTestTypeConversion.java ! test/jdk/lambda/MethodReferenceTestVarArgs.java ! test/jdk/lambda/MethodReferenceTestVarArgsExt.java ! test/jdk/lambda/MethodReferenceTestVarArgsSuper.java ! test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java ! test/jdk/lambda/MethodReferenceTestVarArgsThis.java ! test/jdk/lambda/TestInnerCtorRef.java ! test/jdk/lambda/TestPrivateCtorRef.java ! test/jdk/lambda/separate/AttributeInjector.java ! test/jdk/lambda/separate/ClassFile.java ! test/jdk/lambda/separate/ClassFilePreprocessor.java ! test/jdk/lambda/separate/ClassToInterfaceConverter.java ! test/jdk/lambda/separate/Compiler.java ! test/jdk/lambda/separate/DirectedClassLoader.java ! test/jdk/lambda/separate/SourceModel.java ! test/jdk/lambda/separate/TestHarness.java ! test/jdk/lambda/shapegen/ClassCase.java ! test/jdk/lambda/shapegen/Hierarchy.java ! test/jdk/lambda/shapegen/HierarchyGenerator.java ! test/jdk/lambda/shapegen/Rule.java ! test/jdk/lambda/shapegen/RuleGroup.java ! test/jdk/lambda/shapegen/TTNode.java ! test/jdk/lambda/shapegen/TTParser.java ! test/jdk/lambda/shapegen/TTShape.java ! test/jdk/lambda/vm/DefaultMethodRegressionTests.java ! test/jdk/lambda/vm/InterfaceAccessFlagsTest.java ! test/jdk/lambda/vm/StrictfpDefault.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/invoke/util/ValueConversionsTest.java ! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java ! test/sun/java2d/cmm/ColorConvertOp/ColConvTest.java ! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html ! test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java ! test/sun/java2d/cmm/ColorConvertOp/MTColConvTest.java ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java ! test/sun/java2d/cmm/ProfileOp/SetDataTest.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/jvmstat/testlibrary/JavaProcess.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/jdp/ClientConnection.java ! test/sun/management/jdp/JdpTestUtil.java ! test/sun/management/jdp/JdpTestUtilTest.java ! test/sun/management/jdp/JdpUnitTest.java ! test/sun/management/jdp/PacketTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/misc/Cleaner/ExitOnThrow.java ! test/sun/misc/FloatingDecimal/OldFDBigIntForTest.java ! test/sun/misc/JavaLangAccess/NewUnsafeString.java ! test/sun/net/ftp/MarkResetTest.java ! test/sun/net/ftp/MarkResetTest.sh ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java ! test/sun/net/www/protocol/http/StackTraceTest.java ! test/sun/nio/cs/EUC_TW_OLD.java ! test/sun/nio/cs/TestIBMBugs.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/X11CNS11643.java ! test/sun/nio/cs/X11CNS11643P1.java ! test/sun/nio/cs/X11CNS11643P2.java ! test/sun/nio/cs/X11CNS11643P3.java ! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java ! test/sun/rmi/log/ReliableLog/SnapshotSize.java ! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java ! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh ! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh ! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java ! test/sun/security/krb5/MicroTime.java ! test/sun/security/krb5/ParseCAPaths.java ! test/sun/security/krb5/ServiceCredsCombination.java ! test/sun/security/krb5/auto/AcceptPermissions.java ! test/sun/security/krb5/auto/AcceptorSubKey.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/DiffNameSameKey.java ! test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/GSSUnbound.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/KeyTabCompat.java ! test/sun/security/krb5/auto/MoreKvno.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/ReplayCacheTest.java ! test/sun/security/krb5/auto/SaslUnbound.java ! test/sun/security/krb5/auto/TwoOrThree.java ! test/sun/security/krb5/auto/UnboundService.java ! test/sun/security/krb5/ccache/EmptyCC.java ! test/sun/security/krb5/config/dns.sh ! test/sun/security/krb5/etype/WeakCrypto.java ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/PolicyFile/Comparator.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/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/crl.sh ! test/sun/security/tools/jarsigner/emptymanifest.sh ! test/sun/security/tools/jarsigner/newsize7.sh ! test/sun/security/tools/jarsigner/onlymanifest.sh ! test/sun/security/tools/jarsigner/passtype.sh ! test/sun/security/tools/jarsigner/samename.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/DummyProvider.java ! test/sun/security/tools/keytool/ListKeychainStore.sh ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/console.sh ! test/sun/security/tools/keytool/emptysubject.sh ! test/sun/security/tools/keytool/importreadall.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/selfissued.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/keytool/trystore.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/sun/security/x509/X509CRLImpl/Verify.java ! test/sun/security/x509/X509CertImpl/Verify.java ! test/sun/tools/jps/jps-V_2.sh ! test/sun/tools/jrunscript/CheckEngine.java ! test/sun/util/calendar/zi/BackEnd.java ! test/sun/util/calendar/zi/Checksum.java ! test/sun/util/calendar/zi/DayOfWeek.java ! test/sun/util/calendar/zi/Gen.java ! test/sun/util/calendar/zi/GenDoc.java ! test/sun/util/calendar/zi/Main.java ! test/sun/util/calendar/zi/Mappings.java ! test/sun/util/calendar/zi/Month.java ! test/sun/util/calendar/zi/Rule.java ! test/sun/util/calendar/zi/RuleDay.java ! test/sun/util/calendar/zi/RuleRec.java ! test/sun/util/calendar/zi/Simple.java ! test/sun/util/calendar/zi/TestZoneInfo310.java ! test/sun/util/calendar/zi/Time.java ! test/sun/util/calendar/zi/Timezone.java ! test/sun/util/calendar/zi/TzIDOldMapping.java ! test/sun/util/calendar/zi/Zone.java ! test/sun/util/calendar/zi/ZoneInfoFile.java ! test/sun/util/calendar/zi/ZoneInfoOld.java ! test/sun/util/calendar/zi/ZoneRec.java ! test/sun/util/calendar/zi/Zoneinfo.java ! test/sun/util/calendar/zi/tzdata/gmt ! test/sun/util/calendar/zi/tzdata/jdk11_backward ! test/sun/util/calendar/zi/tzdata_jdk/gmt ! test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward ! test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward ! test/sun/util/resources/Locale/Bug6275682.java ! test/sun/util/resources/TimeZone/Bug6317929.java ! test/tools/jar/ChangeDir.java ! test/tools/jar/JarEntryTime.java ! test/tools/pack200/NoBeans.java ! test/tools/pack200/Reflect.java Changeset: e1499442453b Author: lana Date: 2013-12-26 22:39 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/e1499442453b Merge ! src/share/classes/javax/swing/text/AbstractDocument.java Changeset: 7e10ee00fe41 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/7e10ee00fe41 Added tag jdk8-b122 for changeset e1499442453b ! .hgtags Changeset: 484e16c0a040 Author: nikgor Date: 2014-01-07 12:17 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/484e16c0a040 8004562: Better support for crossdomain.xml Reviewed-by: herrick, ngthomas, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 13b28cffa140 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/13b28cffa140 Added tag jdk8-b123 for changeset 484e16c0a040 ! .hgtags Changeset: b1663fd9ded9 Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/b1663fd9ded9 Added tag jdk8u20-b00 for changeset 13b28cffa140 ! .hgtags Changeset: e40ac3dcb075 Author: kvn Date: 2014-01-22 17:40 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/e40ac3dcb075 Merge ! make/CompileJavaClasses.gmk ! make/CompileLaunchers.gmk ! make/gendata/GendataFontConfig.gmk ! make/gensrc/GensrcX11Wrappers.gmk ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/awt/medialib/mlib_sys.c ! src/share/native/sun/awt/medialib/mlib_types.h ! src/share/transport/socket/socketTransport.c ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/awt/awt_LoadLibrary.c ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/management/OperatingSystemImpl.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java ! src/windows/native/java/net/net_util_md.c ! src/windows/native/sun/nio/ch/Net.c ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/nio/file/Files/walkFileTree/find.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ServiceLoader/basic.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/net/ftp/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh From vladimir.kozlov at oracle.com Wed Jan 22 20:56:52 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jan 2014 04:56:52 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 44 new changesets Message-ID: <20140123045825.95B31626B3@hg.openjdk.java.net> Changeset: 7469c9ca967a Author: amurillo Date: 2013-12-13 09:48 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/7469c9ca967a 8030062: new hotspot build - hs25-b64 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9ecf408d4568 Author: iveresov Date: 2013-12-12 11:25 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/9ecf408d4568 8029668: Kithcensink crashed with guarantee(Assembler::is_simm13(disp)) failed: Do not match large constant offsets Summary: Bailout if we try to reference a stack location that we can't encode Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad Changeset: 68ec0a75ee22 Author: iignatyev Date: 2013-12-13 00:34 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/68ec0a75ee22 8026941: [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric Reviewed-by: kvn, vlivanov ! test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 8beff993531a Author: iignatyev Date: 2013-12-12 18:57 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/8beff993531a Merge Changeset: 00bcb186fc5a Author: drchase Date: 2013-12-12 15:11 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/00bcb186fc5a 8029351: assert(bt != T_OBJECT) failed: Guard is incorrect in VM:defmeth Summary: replace test condition with reference to the proper predicate, encode folk wisdom into an assert Reviewed-by: twisti, coleenp ! src/share/vm/oops/generateOopMap.cpp Changeset: b00c6d846a0a Author: drchase Date: 2013-12-12 18:00 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/b00c6d846a0a Merge Changeset: ddcb2ac2900d Author: drchase Date: 2013-12-12 20:55 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/ddcb2ac2900d Merge Changeset: 22c88c127fa4 Author: roland Date: 2013-12-13 09:25 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/22c88c127fa4 8029383: assert(counter_changed) failed: failed dependencies, but counter didn't change Summary: no call to SystemDictionary::notice_modification() when class is defined through Unsafe.defineAnonymousClass() can caused missed dependency change. Reviewed-by: kvn, twisti ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: a632dd6ef1f9 Author: anoll Date: 2013-12-16 00:44 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/a632dd6ef1f9 Merge Changeset: 61ee6bab0763 Author: amurillo Date: 2013-12-20 08:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/61ee6bab0763 Merge Changeset: adcc814f792a Author: amurillo Date: 2013-12-20 08:43 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/adcc814f792a Added tag hs25-b64 for changeset 61ee6bab0763 ! .hgtags Changeset: 0b9c7eb6658b Author: amurillo Date: 2013-12-20 08:48 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/0b9c7eb6658b 8030752: new hotspot build - hs25-b65 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5832cdaf89c6 Author: hseigel Date: 2013-12-16 08:24 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/5832cdaf89c6 8027804: JCK resolveMethod test fails expecting AbstractMethodError Summary: Create AME overpass methods and fix method search logic Reviewed-by: kamg, acorn, lfoltan, coleenp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 62e87648a4be Author: coleenp Date: 2013-12-19 20:28 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/62e87648a4be 8030633: nsk/jvmti/RedefineClasses/StressRedefine failed invalid method ordering length on Solaris Summary: A method with no declared methods was getting an AME overpass method with the latest change. The method_ordering array was not updated for the new methods. Reviewed-by: dcubed, acorn, dsamersoff, lfoltan, hseigel ! src/share/vm/classfile/defaultMethods.cpp Changeset: be840d0078bc Author: coleenp Date: 2013-12-20 14:03 -0500 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/be840d0078bc Merge Changeset: 55fb97c4c58d Author: mikael Date: 2013-12-24 11:48 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/55fb97c4c58d 8029233: Update copyright year to match last edit in jdk8 hotspot repository for 2013 Summary: Copyright year updated for files modified during 2013 Reviewed-by: twisti, iveresov ! agent/make/Makefile ! agent/src/os/linux/libproc.h ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/os/win32/windbg/sawindbg.cpp ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/minimal1.make ! make/hotspot.script ! make/linux/makefiles/adlc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/saproc.make ! make/sa.files ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/windows/build_vm_def.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/jni_zero.h ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/bsd/dtrace/jvm_dtrace.c ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/bytecodeAssembler.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTrace.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/perf.cpp ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.hpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/memoryUsage.hpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! test/Makefile ! test/TEST.ROOT ! test/compiler/5091921/Test7005594.sh ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/compiler/8000805/Test8000805.java ! test/compiler/8005419/Test8005419.java ! test/gc/6941923/Test6941923.java ! test/gc/g1/TestHumongousAllocInitialMark.java ! test/runtime/6626217/Test6626217.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7162488/Test7162488.sh ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: d3521d8e562a Author: amurillo Date: 2013-12-27 07:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/d3521d8e562a Added tag hs25-b65 for changeset 55fb97c4c58d ! .hgtags Changeset: 591135a7d6f9 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/591135a7d6f9 Added tag jdk8-b122 for changeset d3521d8e562a ! .hgtags Changeset: c89630a122b4 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/c89630a122b4 Added tag jdk8-b123 for changeset 591135a7d6f9 ! .hgtags Changeset: cb2e4b603dcb Author: coffeys Date: 2014-01-11 17:18 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/cb2e4b603dcb Added tag jdk8u20-b00 for changeset c89630a122b4 ! .hgtags Changeset: 985a60c5630e Author: amurillo Date: 2014-01-11 13:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/985a60c5630e Added tag hs25.20-b00 for changeset c89630a122b4 ! .hgtags Changeset: 1e5c86da8392 Author: amurillo Date: 2014-01-11 13:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/1e5c86da8392 8031552: Update the Hotspot version numbers in Hotspot for JDK 8U Reviewed-by: jcoomes ! make/hotspot_version Changeset: 908afcc9d1cb Author: anoll Date: 2013-12-17 08:31 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/908afcc9d1cb 8029091: Bug in calculation of code cache sweeping interval Summary: Use signed data type so that no underflow can happen Reviewed-by: kvn, roland ! src/share/vm/runtime/sweeper.cpp Changeset: d6e7180abab5 Author: anoll Date: 2013-12-19 06:09 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/d6e7180abab5 8026478: -XX:+VerifyAdapterSharing is broken Summary: Fix by considering all checks in StubRoutines Reviewed-by: kvn, twisti ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 6aa49042b101 Author: anoll Date: 2013-12-19 14:08 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/6aa49042b101 8025277: Add -XX: flag to print code cache sweeper statistics Summary: New diagnostic flag prints statistics about the code cache sweeper Reviewed-by: kvn Contributed-by: tobi.hartmann at gmail.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: 5a83a5546dc7 Author: anoll Date: 2013-12-20 10:29 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/5a83a5546dc7 8030783: Provide regression test for 8026478: -XX:+VerifyAdapterSharing is broken Summary: Added simple regression test Reviewed-by: iveresov + test/compiler/debug/VerifyAdapterSharing.java Changeset: 71f0ee9bbf0e Author: anoll Date: 2013-12-20 10:31 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/71f0ee9bbf0e 8028052: compiler/startup/SmallCodeCacheStartup.java fails there is no 'no space to run compiler' in the output Summary: Weaken test so that configurations that have no C1 compiler pass Reviewed-by: iveresov ! test/compiler/startup/SmallCodeCacheStartup.java Changeset: 6d2fe9c23878 Author: iveresov Date: 2013-12-26 21:00 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/6d2fe9c23878 8027388: JVM crashes with SIGSEGV (0xb) at pc=0x00000001077cbbf6 Summary: Make object non-scalarizable if it has field with multiple bases one of which is null Reviewed-by: kvn, twisti ! src/share/vm/opto/escape.cpp Changeset: d1760952ebdd Author: iignatyev Date: 2013-12-31 19:26 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/d1760952ebdd 8028587: New tests development for intrisics for basic operators - add, neg, inc, dec, sub, mul Reviewed-by: twisti Contributed-by: anton.ivanov at oracle.com + test/compiler/intrinsics/mathexact/sanity/AddExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/AddExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/IntrinsicBase.java + test/compiler/intrinsics/mathexact/sanity/MathIntrinsic.java + test/compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/Verifier.java ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java Changeset: 29463147336b Author: roland Date: 2014-01-07 12:38 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/29463147336b 8028536: Test cases to cover type system fixes pushed with 8024070 Summary: extra test cases for type speculation Reviewed-by: kvn ! test/compiler/types/TypeSpeculation.java Changeset: f834ae379225 Author: roland Date: 2014-01-07 14:36 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/f834ae379225 8028064: tiered may collect wrong receiver type at virtual call Summary: when unique callee is known at compile time, recorded class may be wrong Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 5231c2210388 Author: roland Date: 2014-01-07 16:02 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/5231c2210388 8027571: fatal error: meet not symmetric Summary: meet of one constant array and one exact array not symmetric. Reviewed-by: kvn ! src/share/vm/opto/type.cpp + test/compiler/types/TestMeetTopArrayExactConstantArray.java Changeset: 69dc1be43fce Author: roland Date: 2014-01-08 09:49 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/69dc1be43fce 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV Summary: May end up in uncommon trap blob/deopt blob with unguarded stack Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/uncommontrap/StackOverflowGuardPagesOff.java Changeset: df8573b1a44c Author: adlertz Date: 2014-01-08 12:05 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/df8573b1a44c 8029446: assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections Summary: Added loadConP0 projection node to block in case of re-materialization of the loadConP0. x86_64 only. Reviewed-by: kvn ! src/share/vm/opto/chaitin.cpp Changeset: 849eb7bfceac Author: kvn Date: 2014-01-08 10:25 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/849eb7bfceac 8028468: Add inlining information into ciReplay Summary: Allow dump and replay inlining for specified method during a program execution. Reviewed-by: roland, twisti ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ef54656d5a65 Author: adlertz Date: 2014-01-09 10:47 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/ef54656d5a65 8011391: C1: assert(code_offset() - offset == NativeInstruction::nop_instruction_size) failed: only one instruction can go in a delay slot Summary: Remove the VerifyOopMaps flag which doesn't work for tiered or for C1 with more compiler threads than one. Reviewed-by: twisti, drchase, iveresov ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: 9f4f77ef2706 Author: iignatyev Date: 2014-01-09 19:03 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/9f4f77ef2706 8031115: intrinsics for Math.decrementExact(J) and incrementExact(J) don't work Reviewed-by: kvn, twisti ! src/share/vm/classfile/vmSymbols.hpp Changeset: 7b9127b17b7a Author: anoll Date: 2014-01-10 06:36 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/7b9127b17b7a 8022494: Make compilation IDs sequential Summary: Use atomic operations to provide sequential compilation IDs Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 84df3d405315 Author: roland Date: 2014-01-13 16:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/84df3d405315 8029464: assert(ft == ttkp->cast_to_ptr_type(jtkp->ptr()) || ft->isa_narrowoop() Summary: Fix the assert check for narrow klass pointer. Reviewed-by: twisti, kvn ! src/share/vm/opto/cfgnode.cpp Changeset: d7773b29c65a Author: roland Date: 2014-01-14 12:44 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/d7773b29c65a 8030662: "assert(counter_changed) failed: failed dependencies, but counter didn't change" still fails Summary: Erroneously removed call to SystemDictionary::notice_modification() from jvmti with fix for 8029383 Reviewed-by: iveresov, twisti, kvn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: add2caa66e7e Author: roland Date: 2014-01-14 14:51 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/add2caa66e7e 8026253: New type profiling points: sparc support Summary: c1 and interpreter support for new type profiling on sparc Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 412d3b5fe90e Author: amurillo Date: 2014-01-16 17:18 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/412d3b5fe90e Merge ! .hgtags Changeset: 22cfca978a03 Author: amurillo Date: 2014-01-16 17:18 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/22cfca978a03 Added tag hs25.20-b01 for changeset 412d3b5fe90e ! .hgtags Changeset: a9becfeecd1b Author: kvn Date: 2014-01-22 17:42 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/a9becfeecd1b Merge ! agent/src/os/linux/libproc.h ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/os/posix/vm/os_posix.hpp ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/macros.hpp From david.holmes at oracle.com Wed Jan 22 21:53:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jan 2014 15:53:06 +1000 Subject: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F125@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE707E1@DEWDFEMB12A.global.corp.sap> <52B3A3AF.9050609@oracle.com> <52D76E6F.8070504@oracle.com> <52D821CB.6020207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D010@DEWDFEMB12A.global.corp.sap> <52DC8DA9.2010106@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8D974@DEWDFEMB12A.global.corp.sap> <52DDE01D.1060605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8F125@DEWDFEMB12A.global.corp.sap> Message-ID: <52E0AE42.7050306@oracle.com> On 23/01/2014 12:01 AM, Lindenmaier, Goetz wrote: > Hi, > > thanks for the hint to this paper, David! > We modified the known read-after-write test to use the serialization page > mechanism, and reading that paper we were able to understand it is correct > on X86 / TSO. Thanks to Andreas Schoesser for this. > http://cr.openjdk.java.net/~goetz/raw_serialization_page/raw_s11n_page.cpp > > We ran the test on linux ppc and aix over the weekend, without failure. > This indicates the mechanism works there, too. Well, as you know, testing can only prove the presence of bugs ... The conditions under which this might fail are subtle and might never arise in a direct test. > The test fails immediately if the "write" in the fast thread is omitted. > We also checked that both threads make considerable progress, and the > fast thread does not always trap. > > Also, we looked at documentation about how mprotect etc should > be implemented on ppc. > A mprotect should do a tlbie, invidating the TLBs of all processors. > It also should do an eieio and a tlbsync > This assures the TLB of the "fast" process doing only the write is > invalidated before mprotect returns. So the fast thread will > experience a TLB-miss on the write. We assume on the TLB-miss > some synchronization instruction is used, probably the ptesync. > This should assure the fast thread gets the new value even if the > page is already writable again. > Unfortunately this is implemented in supervisor code, which is not > available to us. > > I'll add a patch that enables UseMembar in our VM to test the performance > impacts of that variant. > As I don't see a good reason this flag is product, I'll change it to > debug for the test. There are very good reasons for it being a product flag as it has proven invaluable over the years in identifying memory-ordering race conditions ie missing barriers. As you described, the flag should be set depending on > whether the serialization page works. So nowadays it serves as a platform > configuration so I think debug is the better choice. > (Btw, you could move UsePPCLWSYNC into your globals_ppc.hpp with the new > platform-dependent flags.) I never realized it was there else I would have moved it long ago. Thanks, David > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 21. Januar 2014 03:49 > To: Lindenmaier, Goetz; Vladimir Kozlov > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' > Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization > > On 20/01/2014 11:41 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I understand your arguments and basically agree with them. >> If the serialization page does not work on PPC, your solution >> 1) is best. >> >> But I'm not sure why there should be a link between TSO and whether >> the serialization page trick works. Second depends, as you say, >> on the OS implementation. > > My limited understanding is that on RMO-based systems the requirements for: > > "Synchronization based on page-protections - mprotect()" > > as described in: > > http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt > > may not always hold. Dave Dice would need to provide more details if needed. > > Cheers, > David > >> I would assume that the write to the serialization page causes >> the OS to generate a new TLB entry or the like, involving the >> use of a ptwsync instruction which would be fine. But we are >> investigating this. >> >> We are also experimenting with a small regression test to find >> out whether the serialization page ever fails. >> >> Best regards, >> Goetz. >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 20. Januar 2014 03:45 >> To: Lindenmaier, Goetz; Vladimir Kozlov >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' >> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization >> >> On 17/01/2014 11:30 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I had a look at the first part of this issue: Whether StoreStore >>> is necessary in the interpreter. Let's for now assume the serialization >>> page mechanism works on PPC. >>> >>> In the state transition leaving the VM state, which is executed in the >>> destructor, ThreadStateTransition::transition() is called, which executes >>> if (UseMembar) { >>> OrderAccess::fence(); >>> } else { >>> os::write_memory_serialize_page(thread); >>> } >>> >>> os:: write_memory_serialize_page() can not be considered a proper >>> MemBar, as it only serializes if another thread poisoned the page. >>> Thus it does not qualify to order the initialization and the publishing >>> of the object. >>> >>> You are right, if UseMembar is true, the StoreStore in the interpreter >>> is superfluous. We could guard the StoreStores in the interpreter by >>> !UseMembar. >> >> My understanding, from our existing non-TSO system ports, is that the >> present assumption is that either: >> >> a) you have a TSO system, in which case you are probably using the >> serialization page, but you don't need any barrier to enforce ordering >> anyway; or >> >> b) you don't have a TSO system, you are using UseMembar==true and so you >> get a full fence inserted that enforces the ordering anyway. >> >> So the ordering requirements are satisfied by piggy-backing on the >> UseMembar setting that comes from the thread state transition code, >> which forms part of the "runtime entry" code. That's not to say that you >> will necessarily find this applied consistently in all places where it >> might be applied - nor will you necessarily find that this is common >> knowledge amongst VM engineers. >> >> Technically the storeStore barriers could be conditional on !UseMembar >> but that is redundant in the current usage. >> >>> But then again, one is to order the publishing of the thread states, >>> the other to enforce some Java semantics. I don't know whether everybody >>> who changes in one place is aware of both issues. But if you want to, >>> I'll add a !UseMembar in the interpreter. >> >> Here are my preferred options in order: >> >> 1. Set UseMembar==true on PPC64 and drop these new storeStore barriers - >> rely on the piggy-backing effect. >> >> 2. Conditionalize the new storeStore barriers on !UseMembar. This >> unfortunately penalizes all platforms with a runtime check. >> >> 3. Add the storeStores unconditionally. This penalizes platforms that >> set UseMembar==true as we will now get two fences at runtime. >> >> I know we're talking about the interpreter here so performance is not >> exactly critical, but still ... >> >>> Maybe it would be a good idea >>> to document the double use in interfaceSupport.cpp, too. And maybe >>> add an assertion of some kind. >> >> interfaceSupport doesn't know that other code piggy-backs on the fact >> state-transitions have full fences when UseMembar is true. If it is >> documented anywhere it should be in the interpreter (and any other >> places that makes the same assumption) - something like: >> >> // On non-TSO systems there can be additional ordering constraints >> // between Java-level actions (such as allocation and constructor >> // invocation) that in principle need explicit memory barriers. >> // However, on many non-TSO systems the thread-state transition logic >> // in the IRT_ENTRY code will insert a full fence due to the use of >> // UseMembar==true, which provides the necessary ordering guarantees. >> >>> >>> We're digging into the other issue currenty, whether the serialization page >>> works on ppc. We understand your concerns and have no simple answer to >>> it right now. At least, in our VM and in the port there are no known problems >>> with the state transitions. >> >> Even if the memory serialization page does not work, in a guaranteed >> sense, on PPC-AIX, it is extremely unlikely that testing would expose >> this. Also note that the memory serialization page behaviour is more a >> function of the OS - so it may be that AIX is different to linux in that >> regard. >> >> Cheers, >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Donnerstag, 16. Januar 2014 19:16 >>> To: David Holmes; Lindenmaier, Goetz >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev Source Developers' >>> Subject: Re: RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization >>> >>> Changes are in C++ Interpreter so it does not affect Oracle VM. >>> But David has point here. I would like to hear the explanation too. >>> >>> BTW, I see that for ppc64: >>> >>> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false); >>> >>> as result write_memory_serialize_page() is used in >>> ThreadStateTransition::transition(). >>> >>> Is it not enough on PPC64? >>> >>> Thanks, >>> Vladimir >>> >>> On 1/15/14 9:30 PM, David Holmes wrote: >>>> Can I get some response on this please - specifically the redundancy wrt >>>> IRT_ENTRY actions. >>>> >>>> Thanks, >>>> David >>>> >>>> On 20/12/2013 11:55 AM, David Holmes wrote: >>>>> Still catching up ... >>>>> >>>>> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> this change adds StoreStore barriers after object initialization and >>>>>> after constructor calls in the C++ interpreter. This assures no >>>>>> uninitialized >>>>>> objects or final fields are visible. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/ >>>>> >>>>> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize >>>>> thread state transitions that already include a full "fence" so the >>>>> storestore barriers are redundant in those cases. >>>>> >>>>> The fastpath _new storestore seems okay. >>>>> >>>>> I don't know how handle_return gets used to know if it is reasonable or >>>>> not. >>>>> >>>>> I was trying, unsuccessfully, to examine the same code in the >>>>> templateInterpreter to see how it handles these cases as it naturally >>>>> has the same object-initialization-safety requirements (though these can >>>>> be handled in a number of different ways other than an unconditional >>>>> storestore barrier at the end of the initialization and construction >>>>> phases. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Please review and test this change. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From david.holmes at oracle.com Wed Jan 22 22:10:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jan 2014 16:10:55 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52B3CE56.9030205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> <52DFF98C.8010001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap> Message-ID: <52E0B26F.1000105@oracle.com> On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> Yes, I will backport it. > That's good, thank you! > >> I will build bundles and give them to SQE for final testing. > __final__ That's even better, that's great!!! Hmmm I still have reservations concerning the _thread_state changes that were pushed. David ----- > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 22. Januar 2014 18:02 > To: Lindenmaier, Goetz > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz > > On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> Thanks for testing and pushing! >> >> Will you push this also to stage? I assume we can handle this >> as the other three hotspot changes, without a new bug-id? > > Yes, I will backport it. > > What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581? > Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix > from jdk9. Or I am mistaking? > >> >> Also, when do you think we (you unfortunately) should update >> the repos again? Stage-9 maybe after Volkers last change is submitted? > > After I test and push 8031581 I will do sync with latest jdk9 sources (b01). > I will build bundles and give them to SQE for final testing. > > Thanks, > Vladimir > >> >> Best regards, >> Goetz >> >> >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Dienstag, 21. Januar 2014 21:00 >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Thanks. I am pushing it. >> >> Vladimir >> >> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >>> Sorry, I missed that. fixed. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 21. Januar 2014 12:53 >>> To: Lindenmaier, Goetz; Vladimir Kozlov >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Thanks Goetz! >>> >>> This typo still exists: >>> >>> + bool _wrote_volatile; // Did we write a final field? >>> >>> s/final/volatile/ >>> >>> Otherwise no further comments from me. >>> >>> David >>> >>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I made a new webrev >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>>> differing from >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>> only in the comments. >>>> >>>> I removed >>>> // Support ordering of "Independent Reads of Independent Writes". >>>> everywhere, and edited the comments in the globalDefinition*.hpp >>>> files. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 21. Januar 2014 05:55 >>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Hi Goetz, >>>> >>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I tried to come up with a webrev that implements the change as proposed in >>>>> your mails: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>> >>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>>> >>>> Given the flag name the commentary eg: >>>> >>>> + // Support ordering of "Independent Reads of Independent Writes". >>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>>> >>>> seems somewhat redundant. >>>> >>>>> I left the definition and handling of _wrote_volatile in the code, without >>>>> any protection. >>>> >>>> + bool _wrote_volatile; // Did we write a final field? >>>> >>>> s/final/volatile >>>> >>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>>>> and put it on one line. >>>>> >>>>> I removed the comment in library_call.cpp. >>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>>>> from the comments as it's PPC specific. >>>> >>>> I think the primary IRIW comment/explanation should go in >>>> globalDefinitions.hpp where >>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>>> >>>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>>>> issues in C1 if nobody did it by then. >>>> >>>> I've filed: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>>> >>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >>>> platforms" >>>> >>>> to cover this task, as it may be needed sooner rather than later. >>>> >>>>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >>>> >>>> Ok. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>>>> want to keep it this way, it could be useful to have such info on other >>>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>>> parse.hpp. >>>>>>>> >>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>>>> which could be checked in all places instead of #ifdef: >>>>>>> >>>>>>> I asked for the ifdef some time back as I find it much preferable to >>>>>>> have this as a build-time construct rather than a >>>>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>>>> use it. >>>>>> >>>>>> Any decent C++ compiler will optimize expressions with such constants >>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>>>> >>>>> If you insist then we may as well do it all the same way. Better to be >>>>> consistent. >>>>> >>>>> My apologies Goetz for wasting your time going back and forth on this. >>>>> >>>>> That aside I have a further concern with this IRIW support - it is >>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>>>> this is going on then we (which probably means the Oracle 'we') need to >>>>> add the missing C1 code. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>>> #else >>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>>> #endif >>>>>>>> >>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>>> >>>>>>>> and then: >>>>>>>> >>>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>>> OrderAccess::fence(); \ >>>>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>>> >>>>>>>> And: >>>>>>>> >>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>>> field->is_volatile()) { >>>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>>> + } >>>>>>>> >>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>>>> >>>>>>>> The code in parse1.cpp could be put on one line: >>>>>>>> >>>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>>> method()->is_initializer()) )) { >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> I updated the webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>> >>>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>>> I also think it's better to separate these this way. >>>>>>>>> >>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>>> please. >>>>>>>>> >>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>>> ppc specific stuff in a shared file: >>>>>>>>> >>>>>>>>> if (is_volatile) { >>>>>>>>> ! if (!is_store) { >>>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>>> ! } else { >>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>>> + #endif >>>>>>>>> + } >>>>>>>>> >>>>>>>>> I don't think the comment is needed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks for your comments! >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>>> >>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>>>> specifically it is >>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>>>> Seems >>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>>>> >>>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>>> discussed >>>>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>>>> PPC64 porters. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>>>> this version. >>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>>> To: David Holmes >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>>>> not >>>>>>>>>>>> required to pass. >>>>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>>>> worked >>>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>>>> it by >>>>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>>>> part is >>>>>>>>>>> not that performance relevant. >>>>>>>>>>> >>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>>> think >>>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz >>>>>>>>>>> >>>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>>>> emails. >>>>>>>>>>> >>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>>>> settled. >>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>>>> >>>>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>>>> The change is about IRIW. >>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>>> >>>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>>>> But I'm >>>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>>> >>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>>>> stores. >>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>>> constructor tests. >>>>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>>>> after stores >>>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>>> >>>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>>> were not >>>>>>>>>>> required to pass. >>>>>>>>>>> >>>>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>>>> order >>>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>>>> The only instruction >>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>>>> therefore the >>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>>>> proper representation >>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>>>> it's pointless >>>>>>>>>>>> anyways. >>>>>>>>>>>> >>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>> >>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>> think >>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>>>> Or also >>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> TL;DR version: >>>>>>>>>>>> >>>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>>> constructor-barrier >>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>>>> *may* >>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>>>> ensure >>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>>> invalid >>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>>>> need it >>>>>>>>>>>> due to other factors). >>>>>>>>>>>> >>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>>>> term :) >>>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>>> >>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>>> visible to >>>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>>> architectures >>>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>>> >>>>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>>>> ARM and >>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>>> >>>>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>>> > and place it before loads. >>>>>>>>>>>> >>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>>>> after >>>>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>>>> same >>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>>>> load - >>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>>>> clearer. >>>>>>>>>>>> >>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>>> implemented as >>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>>>> hooks >>>>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>>> >>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>>>> this >>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> I did not yet add the >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>> or >>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>>> >>>>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>>> >>>>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>>>> store >>>>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> @David >>>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>>> continuous. >>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>>>> issue. >>>>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>>>> you >>>>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>>>> solution, >>>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>>>> issues. >>>>>>>>>>>>> >>>>>>>>>>>>> @David >>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>>>> and >>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>>>> ARM and >>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>>>> used 'read' >>>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>>>> above). >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>>> processors >>>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>>> >>>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>>> >>>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>>>> a few >>>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>>>> problem yet, >>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>> >>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>> continuous. >>>>>>>>>>>>> >>>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>>> different?) >>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>>>> I contributed a >>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>>>> are evaluated >>>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>>> problem >>>>>>>>>>>>>> is that >>>>>>>>>>>>>> store >>>>>>>>>>>>>> sync >>>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>>> only >>>>>>>>>>>>>> sync >>>>>>>>>>>>>> load >>>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>>> pass that test. >>>>>>>>>>>>> >>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>>> term and >>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>>> store >>>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>>>> that >>>>>>>>>>>>>> do what is required. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>>> initializing >>>>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>>> volatiles do >>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>>>> that >>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>>>> Aleksey >>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>>>> account >>>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>>> An example: >>>>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>>>> read >>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>>>> few >>>>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>>>> will >>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>>> moment. The >>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>>> requirements for >>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>>>> are not >>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>>>> store >>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>>>> software >>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>>>> don't have >>>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>>>> I will >>>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>>>> it might >>>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>>>> them). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>>>> way :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>>>> fix an >>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>>>> doing the >>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>>> performance >>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>>> properties >>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>>>> reduce >>>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>>>> under >>>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>>> like this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>>>> David? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> From vladimir.kozlov at oracle.com Wed Jan 22 22:55:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 22:55:57 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52E0B26F.1000105@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> <52DFF98C.8010001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap> <52E0B26F.1000105@oracle.com> Message-ID: <52E0BCFD.8020202@oracle.com> Okay, lets resolve it. David, are you talking about this change?: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/diff/3205e78d8193/src/share/vm/runtime/thread.hpp Which may penalize our binaries without need. I think Goetz suggested already to put it under #ifdef PPC64 but I may be misremember. Would #ifdef solution satisfy you? Thanks, Vladimir On 1/22/14 10:10 PM, David Holmes wrote: > On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Yes, I will backport it. >> That's good, thank you! >> >>> I will build bundles and give them to SQE for final testing. >> __final__ That's even better, that's great!!! > > Hmmm I still have reservations concerning the _thread_state changes that were pushed. > > David > ----- > >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Mittwoch, 22. Januar 2014 18:02 >> To: Lindenmaier, Goetz >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz >> >> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> Thanks for testing and pushing! >>> >>> Will you push this also to stage? I assume we can handle this >>> as the other three hotspot changes, without a new bug-id? >> >> Yes, I will backport it. >> >> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581? >> Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix >> from jdk9. Or I am mistaking? >> >>> >>> Also, when do you think we (you unfortunately) should update >>> the repos again? Stage-9 maybe after Volkers last change is submitted? >> >> After I test and push 8031581 I will do sync with latest jdk9 sources (b01). >> I will build bundles and give them to SQE for final testing. >> >> Thanks, >> Vladimir >> >>> >>> Best regards, >>> Goetz >>> >>> >>> >>> -----Original Message----- >>> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>> Sent: Dienstag, 21. Januar 2014 21:00 >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Thanks. I am pushing it. >>> >>> Vladimir >>> >>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >>>> Sorry, I missed that. fixed. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 21. Januar 2014 12:53 >>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Thanks Goetz! >>>> >>>> This typo still exists: >>>> >>>> + bool _wrote_volatile; // Did we write a final field? >>>> >>>> s/final/volatile/ >>>> >>>> Otherwise no further comments from me. >>>> >>>> David >>>> >>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I made a new webrev >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>>>> differing from >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>> only in the comments. >>>>> >>>>> I removed >>>>> // Support ordering of "Independent Reads of Independent Writes". >>>>> everywhere, and edited the comments in the globalDefinition*.hpp >>>>> files. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Dienstag, 21. Januar 2014 05:55 >>>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I tried to come up with a webrev that implements the change as proposed in >>>>>> your mails: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>>> >>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>>>> >>>>> Given the flag name the commentary eg: >>>>> >>>>> + // Support ordering of "Independent Reads of Independent Writes". >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>>>> >>>>> seems somewhat redundant. >>>>> >>>>>> I left the definition and handling of _wrote_volatile in the code, without >>>>>> any protection. >>>>> >>>>> + bool _wrote_volatile; // Did we write a final field? >>>>> >>>>> s/final/volatile >>>>> >>>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>>>>> and put it on one line. >>>>>> >>>>>> I removed the comment in library_call.cpp. >>>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>>>>> from the comments as it's PPC specific. >>>>> >>>>> I think the primary IRIW comment/explanation should go in >>>>> globalDefinitions.hpp where >>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>>>> >>>>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>>>>> issues in C1 if nobody did it by then. >>>>> >>>>> I've filed: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>>>> >>>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >>>>> platforms" >>>>> >>>>> to cover this task, as it may be needed sooner rather than later. >>>>> >>>>>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >>>>> >>>>> Ok. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>>>> To: Vladimir Kozlov >>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>>> >>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>>>>> want to keep it this way, it could be useful to have such info on other >>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>>>> parse.hpp. >>>>>>>>> >>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>>>>> which could be checked in all places instead of #ifdef: >>>>>>>> >>>>>>>> I asked for the ifdef some time back as I find it much preferable to >>>>>>>> have this as a build-time construct rather than a >>>>>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>>>>> use it. >>>>>>> >>>>>>> Any decent C++ compiler will optimize expressions with such constants >>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>>>>> >>>>>> If you insist then we may as well do it all the same way. Better to be >>>>>> consistent. >>>>>> >>>>>> My apologies Goetz for wasting your time going back and forth on this. >>>>>> >>>>>> That aside I have a further concern with this IRIW support - it is >>>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>>>>> this is going on then we (which probably means the Oracle 'we') need to >>>>>> add the missing C1 code. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>>>> #else >>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>>>> >>>>>>>>> and then: >>>>>>>>> >>>>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>>>> OrderAccess::fence(); \ >>>>>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>>>> >>>>>>>>> And: >>>>>>>>> >>>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>>>> field->is_volatile()) { >>>>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>>>> + } >>>>>>>>> >>>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>>>>> >>>>>>>>> The code in parse1.cpp could be put on one line: >>>>>>>>> >>>>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>>>> method()->is_initializer()) )) { >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> I updated the webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>> >>>>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>>>> I also think it's better to separate these this way. >>>>>>>>>> >>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>>>> please. >>>>>>>>>> >>>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>>>> ppc specific stuff in a shared file: >>>>>>>>>> >>>>>>>>>> if (is_volatile) { >>>>>>>>>> ! if (!is_store) { >>>>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>>>> ! } else { >>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>>>> + #endif >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>>> I don't think the comment is needed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks for your comments! >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>>>> >>>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>>>>> specifically it is >>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>>>>> Seems >>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>>>>> >>>>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>>>> discussed >>>>>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>>>>> PPC64 porters. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>>>>> this version. >>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>>>> To: David Holmes >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>>>>> not >>>>>>>>>>>>> required to pass. >>>>>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>>>>> worked >>>>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>>>>> it by >>>>>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>>>>> part is >>>>>>>>>>>> not that performance relevant. >>>>>>>>>>>> >>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>>>> think >>>>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz >>>>>>>>>>>> >>>>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>>>>> emails. >>>>>>>>>>>> >>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>>>>> settled. >>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>>>>> >>>>>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>>>>> The change is about IRIW. >>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>>>> >>>>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>>>>> But I'm >>>>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>>>> >>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>>>>> stores. >>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>>>> constructor tests. >>>>>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>>>>> after stores >>>>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>>>> >>>>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>>>> were not >>>>>>>>>>>> required to pass. >>>>>>>>>>>> >>>>>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>>>>> order >>>>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>>>>> The only instruction >>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>>>>> therefore the >>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>>>>> proper representation >>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>>>>> it's pointless >>>>>>>>>>>>> anyways. >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>> >>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>>> think >>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>>>>> Or also >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> TL;DR version: >>>>>>>>>>>>> >>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>>>> constructor-barrier >>>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>>>>> *may* >>>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>>>>> ensure >>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>>>> invalid >>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>>>>> need it >>>>>>>>>>>>> due to other factors). >>>>>>>>>>>>> >>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>>>>> term :) >>>>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>>>> >>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>>>> visible to >>>>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>>>> architectures >>>>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>>>> >>>>>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>>>>> ARM and >>>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>>>> >>>>>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>>>> > and place it before loads. >>>>>>>>>>>>> >>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>>>>> after >>>>>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>>>>> same >>>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>>>>> load - >>>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>>>>> clearer. >>>>>>>>>>>>> >>>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>>>> implemented as >>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>>>>> hooks >>>>>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>>>>> this >>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> I did not yet add the >>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>> or >>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>>>>> store >>>>>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> @David >>>>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>>>> continuous. >>>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>>>>> issue. >>>>>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>>>>> you >>>>>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>>>>> solution, >>>>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>>>>> issues. >>>>>>>>>>>>>> >>>>>>>>>>>>>> @David >>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>>>>> ARM and >>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>>>>> used 'read' >>>>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>>>>> above). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>>>> processors >>>>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>>>> >>>>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>>>>> a few >>>>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>>>>> problem yet, >>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>>> continuous. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>>>> different?) >>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>>>>> I contributed a >>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>>>>> are evaluated >>>>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>> is that >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> sync >>>>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>>>> only >>>>>>>>>>>>>>> sync >>>>>>>>>>>>>>> load >>>>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>>>> pass that test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>>>> term and >>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> do what is required. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>>>> initializing >>>>>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>>>> volatiles do >>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>>>>> Aleksey >>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>>>>> account >>>>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>>>> An example: >>>>>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>>>>> read >>>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>>>>> few >>>>>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>>>> moment. The >>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>>>> requirements for >>>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>>>>> are not >>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>>>>> software >>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>>>>> don't have >>>>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>>>>> I will >>>>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>>>>> it might >>>>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>>>>> them). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>>>>> way :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>>>>> fix an >>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>>>>> doing the >>>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>>>> performance >>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>>>> properties >>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>>>>> reduce >>>>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>>>>> under >>>>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>>>> like this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>>>>> David? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> From volker.simonis at gmail.com Thu Jan 23 00:22:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jan 2014 09:22:39 +0100 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E05FCE.1040901@oracle.com> References: <52E059DF.50600@oracle.com> <52E05FCE.1040901@oracle.com> Message-ID: Hi, I've reported this last week on the build-dev list ("Build error on Mac with 7u51 boot jdk because JObjC.jar was removed from 7u51", http://mail.openjdk.java.net/pipermail/build-dev/2014-January/011566.html), but didn't get any answer yet. The only workaround seems to be to use an older boot JDK as already mentioned by Henry. Unfortunately the problem is a little obscure because both, 8021271 which caused the problem as well as 8021266 which according to Henry will solve the problem are not visible because they are considered "security relevant". Regards, Volker On Thu, Jan 23, 2014 at 1:18 AM, Henry Jen wrote: > I haven't tried this, but Tim Bell mentioned this in an email inquiry I had > earlier, > >> This will be cured when the fix for 8021266 is pushed to JDK 9 (see >> attached). >> >> In the meantime, the workaround in JPRT is to submit your JDK 9 jobs >> with '-bootproduct jdk7u7' since the 7u51 release can not serve as a >> boot JDK. > > > Cheers, > Henry > > > > On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: >> >> I need help. >> >> I am trying to do control build in JPRT after I merged latest jdk9 source: >> >> http://hg.openjdk.java.net/jdk9/jdk9 >> >> to latest ppc64 sources: >> >> http://hg.openjdk.java.net/ppc-aix-port/stage-9 >> >> I have build failure on Mac OS X (on other platforms it passed). See the >> output below. I tried different JPRT queues - the same problem. >> >> During sync I had to merge common/autoconf/toolchain.m4 (merged >> automatically) and regenerate generated-configure.sh. >> >> The latest changes to toolchain.m4 was: >> >> http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 >> >> Next jdk files merge was resolved automatically: >> >> merging make/CompileDemos.gmk >> merging src/solaris/bin/java_md_solinux.c >> merging test/ProblemList.txt >> merging test/tools/launcher/ExecutionEnvironment.java >> 291 files updated, 4 files merged, 14 files removed, 0 files unresolved >> >> Thanks, >> Vladimir >> >> The build failure on Mac OS X: >> >> Cleaning up: >> >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> Outputting classes to: >> >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> Searching for bridged frameworks in: >> >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge >> >> found 3 frameworks >> Parsing XML >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in >> java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at com.apple.jobjc.Coder.(Coder.java:60) >> at >> >> com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) >> >> at >> >> com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) >> >> at >> com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) >> at >> com.apple.internal.jobjc.generator.model.Element.(Element.java:47) >> at >> >> com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) >> >> at >> >> com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) >> >> at >> com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) >> make[2]: *** >> >> [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] >> Error 1 >> make[1]: *** [gensrc-only] Error 2 >> make: *** [jdk-only] Error 2 From Sergey.Bylokhov at oracle.com Thu Jan 23 00:32:37 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Jan 2014 12:32:37 +0400 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E059DF.50600@oracle.com> References: <52E059DF.50600@oracle.com> Message-ID: <52E0D3A5.7050100@oracle.com> On 23.01.2014 3:53, Vladimir Kozlov wrote: > I need help. > > I am trying to do control build in JPRT after I merged latest jdk9 > source: > > http://hg.openjdk.java.net/jdk9/jdk9 Looks like the problem is that 8032348 is not pushed to the master workspace of jdk9, but the bootjdk have this fix. > > to latest ppc64 sources: > > http://hg.openjdk.java.net/ppc-aix-port/stage-9 > > I have build failure on Mac OS X (on other platforms it passed). See > the output below. I tried different JPRT queues - the same problem. > > During sync I had to merge common/autoconf/toolchain.m4 (merged > automatically) and regenerate generated-configure.sh. > > The latest changes to toolchain.m4 was: > > http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 > > Next jdk files merge was resolved automatically: > > merging make/CompileDemos.gmk > merging src/solaris/bin/java_md_solinux.c > merging test/ProblemList.txt > merging test/tools/launcher/ExecutionEnvironment.java > 291 files updated, 4 files merged, 14 files removed, 0 files unresolved > > Thanks, > Vladimir > > The build failure on Mac OS X: > > Cleaning up: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > Outputting classes to: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > Searching for bridged frameworks in: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge > found 3 frameworks > Parsing XML > Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in > java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at com.apple.jobjc.Coder.(Coder.java:60) > at > com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) > at > com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) > at > com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) > at > com.apple.internal.jobjc.generator.model.Element.(Element.java:47) > at > com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) > at > com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) > at > com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) > make[2]: *** > [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] > Error 1 > make[1]: *** [gensrc-only] Error 2 > make: *** [jdk-only] Error 2 -- Best regards, Sergey. From erik.joelsson at oracle.com Thu Jan 23 00:43:10 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Jan 2014 09:43:10 +0100 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E0D3A5.7050100@oracle.com> References: <52E059DF.50600@oracle.com> <52E0D3A5.7050100@oracle.com> Message-ID: <52E0D61E.4090100@oracle.com> On 2014-01-23 09:32, Sergey Bylokhov wrote: > On 23.01.2014 3:53, Vladimir Kozlov wrote: >> I need help. >> >> I am trying to do control build in JPRT after I merged latest jdk9 >> source: >> >> http://hg.openjdk.java.net/jdk9/jdk9 > Looks like the problem is that 8032348 is not pushed to the master > workspace of jdk9, but the bootjdk have this fix. This is correct. The bootjdk in this case is the latest build of jdk8, which has the fix. As soon as the fix is pushed to 9, this will resolve itself. /Erik From goetz.lindenmaier at sap.com Thu Jan 23 05:33:38 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Jan 2014 13:33:38 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52E0BCFD.8020202@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE720F9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> <52DFF98C.8010001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap> <52E0B26F.1000105@oracle.com> <52E0BCFD.8020202@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F71E@DEWDFEMB12A.global.corp.sap> Hi, I tried to avoid #ifdefs, but for performance it makes sense to add them. I'm fine with that. If you agree on this, I will make a webrev. But as I understand, on sparc and x86 that ends up being a volatile store, so there is no big overhead (comparable to issuing a fence operation). Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 23. Januar 2014 07:56 To: David Holmes; Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Okay, lets resolve it. David, are you talking about this change?: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/diff/3205e78d8193/src/share/vm/runtime/thread.hpp Which may penalize our binaries without need. I think Goetz suggested already to put it under #ifdef PPC64 but I may be misremember. Would #ifdef solution satisfy you? Thanks, Vladimir On 1/22/14 10:10 PM, David Holmes wrote: > On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Yes, I will backport it. >> That's good, thank you! >> >>> I will build bundles and give them to SQE for final testing. >> __final__ That's even better, that's great!!! > > Hmmm I still have reservations concerning the _thread_state changes that were pushed. > > David > ----- > >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Mittwoch, 22. Januar 2014 18:02 >> To: Lindenmaier, Goetz >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz >> >> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> Thanks for testing and pushing! >>> >>> Will you push this also to stage? I assume we can handle this >>> as the other three hotspot changes, without a new bug-id? >> >> Yes, I will backport it. >> >> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and new one from today 8031581? >> Should I backport all of them into 8u stage? From conversion between Volker and Alan some of them need backport a fix >> from jdk9. Or I am mistaking? >> >>> >>> Also, when do you think we (you unfortunately) should update >>> the repos again? Stage-9 maybe after Volkers last change is submitted? >> >> After I test and push 8031581 I will do sync with latest jdk9 sources (b01). >> I will build bundles and give them to SQE for final testing. >> >> Thanks, >> Vladimir >> >>> >>> Best regards, >>> Goetz >>> >>> >>> >>> -----Original Message----- >>> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>> Sent: Dienstag, 21. Januar 2014 21:00 >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Thanks. I am pushing it. >>> >>> Vladimir >>> >>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >>>> Sorry, I missed that. fixed. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 21. Januar 2014 12:53 >>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Thanks Goetz! >>>> >>>> This typo still exists: >>>> >>>> + bool _wrote_volatile; // Did we write a final field? >>>> >>>> s/final/volatile/ >>>> >>>> Otherwise no further comments from me. >>>> >>>> David >>>> >>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I made a new webrev >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>>>> differing from >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>> only in the comments. >>>>> >>>>> I removed >>>>> // Support ordering of "Independent Reads of Independent Writes". >>>>> everywhere, and edited the comments in the globalDefinition*.hpp >>>>> files. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Dienstag, 21. Januar 2014 05:55 >>>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I tried to come up with a webrev that implements the change as proposed in >>>>>> your mails: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>>> >>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>>>> >>>>> Given the flag name the commentary eg: >>>>> >>>>> + // Support ordering of "Independent Reads of Independent Writes". >>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>>>> >>>>> seems somewhat redundant. >>>>> >>>>>> I left the definition and handling of _wrote_volatile in the code, without >>>>>> any protection. >>>>> >>>>> + bool _wrote_volatile; // Did we write a final field? >>>>> >>>>> s/final/volatile >>>>> >>>>>> I protected issuing the barrier for volatile in constructors with PPC64_ONLY() , >>>>>> and put it on one line. >>>>>> >>>>>> I removed the comment in library_call.cpp. >>>>>> I also removed the sentence " Solution: implement volatile read as sync-load-acquire." >>>>>> from the comments as it's PPC specific. >>>>> >>>>> I think the primary IRIW comment/explanation should go in >>>>> globalDefinitions.hpp where >>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>>>> >>>>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, we will fix these >>>>>> issues in C1 if nobody did it by then. >>>>> >>>>> I've filed: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>>>> >>>>> "Implement C1 support for IRIW conformance on non-multiple-copy-atomic >>>>> platforms" >>>>> >>>>> to cover this task, as it may be needed sooner rather than later. >>>>> >>>>>> Wrt. to performance: Oracle will soon do heavy testing of the port. If any >>>>>> performance problems arise, we still can add #ifdef PPC64 to circumvent this. >>>>> >>>>> Ok. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>>>> To: Vladimir Kozlov >>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>>>> >>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are trying to >>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef and I >>>>>>>>> want to keep it this way, it could be useful to have such info on other >>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>>>> parse.hpp. >>>>>>>>> >>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp define a value >>>>>>>>> which could be checked in all places instead of #ifdef: >>>>>>>> >>>>>>>> I asked for the ifdef some time back as I find it much preferable to >>>>>>>> have this as a build-time construct rather than a >>>>>>>> runtime one. I don't want to have to pay anything for this if we don't >>>>>>>> use it. >>>>>>> >>>>>>> Any decent C++ compiler will optimize expressions with such constants >>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I really >>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live with it. >>>>>> >>>>>> If you insist then we may as well do it all the same way. Better to be >>>>>> consistent. >>>>>> >>>>>> My apologies Goetz for wasting your time going back and forth on this. >>>>>> >>>>>> That aside I have a further concern with this IRIW support - it is >>>>>> incomplete as there is no C1 support, as PPC64 isn't using client. If >>>>>> this is going on then we (which probably means the Oracle 'we') need to >>>>>> add the missing C1 code. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>>>> #else >>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>>>> >>>>>>>>> and then: >>>>>>>>> >>>>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>>>> OrderAccess::fence(); \ >>>>>>>>> volatile type_name v = OrderAccess::load_acquire((volatile >>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>>>> >>>>>>>>> And: >>>>>>>>> >>>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>>>> field->is_volatile()) { >>>>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>>>> + } >>>>>>>>> >>>>>>>>> And so on. The comments will be needed only in globalDefinitions.hpp >>>>>>>>> >>>>>>>>> The code in parse1.cpp could be put on one line: >>>>>>>>> >>>>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>>>> method()->is_initializer()) )) { >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> I updated the webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>> >>>>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>>>> reflect the new flagging. Also I mention that we support the >>>>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>>>> I also think it's better to separate these this way. >>>>>>>>>> >>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>>>> please. >>>>>>>>>> >>>>>>>>>> One nit I missed before. In src/share/vm/opto/library_call.cpp this >>>>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>>>> ppc specific stuff in a shared file: >>>>>>>>>> >>>>>>>>>> if (is_volatile) { >>>>>>>>>> ! if (!is_store) { >>>>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>>>> ! } else { >>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, sync-load-acquire. >>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>>>> + #endif >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>>> I don't think the comment is needed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks for your comments! >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>>>> >>>>>>>>>>> The general changes to the volatile barriers to support IRIW are okay. >>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this (though more >>>>>>>>>>> specifically it is >>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I find much of >>>>>>>>>>> the commentary excessive, particularly for shared code. In particular >>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to give the >>>>>>>>>>> explanation and I don't think we need it to that level of detail. >>>>>>>>>>> Seems >>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite adequate. >>>>>>>>>>> >>>>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>>>> discussed >>>>>>>>>>> are not required by the Java Memory Model. If you want to keep these >>>>>>>>>>> then I think they should all be guarded with PPC64 because it is not >>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being made by the >>>>>>>>>>> PPC64 porters. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I updated this webrev. I detected a small flaw I made when editing >>>>>>>>>>>> this version. >>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>>>> I also based the webrev on the latest version of the stage repo. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>>>> To: David Holmes >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>>> So we can at least undo #4 now we have established those tests were >>>>>>>>>>>>> not >>>>>>>>>>>>> required to pass. >>>>>>>>>>>> We would prefer if we could keep this in. We want to avoid that it's >>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after they >>>>>>>>>>>> worked >>>>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I would guard >>>>>>>>>>>> it by >>>>>>>>>>>> a flag as proposed. But if you insist I will remove it. Also, this >>>>>>>>>>>> part is >>>>>>>>>>>> not that performance relevant. >>>>>>>>>>>> >>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>>>> think >>>>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz >>>>>>>>>>>> >>>>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two weeks >>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue to check >>>>>>>>>>>> emails. >>>>>>>>>>>> >>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> ok, I understand the tests are wrong. It's good this issue is >>>>>>>>>>>>> settled. >>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of the proof! >>>>>>>>>>>>> >>>>>>>>>>>>> About our change: David, the causality is the other way round. >>>>>>>>>>>>> The change is about IRIW. >>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>>>> >>>>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>>>> implications are not nice for performance on non-TSO platforms. >>>>>>>>>>>> But I'm >>>>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>>>> >>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them after >>>>>>>>>>>>> stores. >>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>>>> constructor tests. >>>>>>>>>>>>> 4. So finally we added them again at the end of the constructor >>>>>>>>>>>>> after stores >>>>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>>>> >>>>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>>>> were not >>>>>>>>>>>> required to pass. >>>>>>>>>>>> >>>>>>>>>>>>> We originally passed the constructor tests because the ppc memory >>>>>>>>>>>>> order >>>>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>>>> operations in the IR. MemBarVolatile is specified as StoreLoad. >>>>>>>>>>>>> The only instruction >>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does StoreStore, >>>>>>>>>>>>> therefore the >>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor tests. The >>>>>>>>>>>>> proper representation >>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. But now >>>>>>>>>>>>> it's pointless >>>>>>>>>>>>> anyways. >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>> >>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime one I >>>>>>>>>>>> think >>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization (something semantic >>>>>>>>>>>> based not architecture based) as that will allows for turning this >>>>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> or the like to guard the customization. I'd like that much better. >>>>>>>>>>>>> Or also >>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> TL;DR version: >>>>>>>>>>>>> >>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>>>> constructor-barrier >>>>>>>>>>>>> for volatiles is not required as part of the JMM specification. It >>>>>>>>>>>>> *may* >>>>>>>>>>>>> be required in an implementation that doesn't pre-zero memory to >>>>>>>>>>>>> ensure >>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>>>> invalid >>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 may >>>>>>>>>>>>> need it >>>>>>>>>>>>> due to other factors). >>>>>>>>>>>>> >>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for correcting the >>>>>>>>>>>>> term :) >>>>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>>>> >>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of buffers and a >>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>>>> visible to >>>>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>>>> architectures >>>>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>>>> >>>>>>>>>>>>> This is the visibility issue that I referred to and affects both >>>>>>>>>>>>> ARM and >>>>>>>>>>>>> PPC. But of course it is normally handled by using suitable barriers >>>>>>>>>>>>> after the stores that need to be visible. I think the crux of the >>>>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>>>> >>>>>>>>>>>>> > The fixes for the constructor issue are only needed because we >>>>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>>>> > and place it before loads. >>>>>>>>>>>>> >>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do the sync >>>>>>>>>>>>> after >>>>>>>>>>>>> the store then you have to do something around the loads to get the >>>>>>>>>>>>> same >>>>>>>>>>>>> results! I still don't know what lead you to the conclusion that the >>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before the >>>>>>>>>>>>> load - >>>>>>>>>>>>> maybe when I get the chance to read that paper in full it will be >>>>>>>>>>>>> clearer. >>>>>>>>>>>>> >>>>>>>>>>>>> So ... the basic problem is that the current structure in the VM has >>>>>>>>>>>>> hard-wired one choice of how to get the right semantics for volatile >>>>>>>>>>>>> variables. You now want to customize that but not all the requisite >>>>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>>>> implemented as >>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- and post- >>>>>>>>>>>>> hooks >>>>>>>>>>>>> that could then be customized per platform. Otherwise you need >>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. I think >>>>>>>>>>>>> this >>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. The barrier >>>>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by Vladimir: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> I did not yet add the >>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>> or >>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation of the JMM >>>>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But we would like to pass the torture test suite as we consider >>>>>>>>>>>>>> this a substantial task in implementing a PPC port. Also we think >>>>>>>>>>>>>> both tests show behavior a programmer would expect. It's bad if >>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and then >>>>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The fixes for the constructor issue are only needed because we >>>>>>>>>>>>>> remove the sync instruction from behind stores (parse3.cpp:320) >>>>>>>>>>>>>> and place it before loads. Then there is no sync between volatile >>>>>>>>>>>>>> store >>>>>>>>>>>>>> and publishing the object. So we add it again in this one case >>>>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> @David >>>>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>>>> continuous. >>>>>>>>>>>>>> That's not true, we did a lot of investigation and testing on this >>>>>>>>>>>>>> issue. >>>>>>>>>>>>>> And we came up with a solution we consider the best possible. If >>>>>>>>>>>>>> you >>>>>>>>>>>>>> have objections, you should at least give the draft of a better >>>>>>>>>>>>>> solution, >>>>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency torture >>>>>>>>>>>>>> issues. >>>>>>>>>>>>>> >>>>>>>>>>>>>> @David >>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the term >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to the >>>>>>>>>>>>>> ARM and >>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy atomicity, I >>>>>>>>>>>>>> used 'read' >>>>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the method name >>>>>>>>>>>>>> above). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>>>> processors >>>>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>>>> >>>>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with >>>>>>>>>>>>>>>> a few >>>>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>>>> Sure. There also is no solution as you require for the taskqueue >>>>>>>>>>>>>>> problem yet, >>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It may have started a year ago but work on it has hardly been >>>>>>>>>>>>>> continuous. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>>>> different?) >>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. Therefore >>>>>>>>>>>>>>> I contributed a >>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, but not >>>>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>>>> So if I can write down a nicer solution testing for methods that >>>>>>>>>>>>>>> are evaluated >>>>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>> is that >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> sync >>>>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>>>> only >>>>>>>>>>>>>>> sync >>>>>>>>>>>>>>> load >>>>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>>>> pass that test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>>>> term and >>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler instructions >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> do what is required. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution that >>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't guaranteed by JMM >>>>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>>>> initializing >>>>>>>>>>>>>>>> a volatile field. Previously, we discussed this with Aleksey >>>>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>>>> volatiles do >>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in the JMM >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug and >>>>>>>>>>>>>>> Aleksey >>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is wrong. We >>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>>>> Basically, I agree on this. But you also have to take into >>>>>>>>>>>>>>>> account >>>>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>>>> An example: >>>>>>>>>>>>>>>> MemBarRelease // means LoadStore, StoreStore barrier >>>>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code looks like >>>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>>> MemBarRelease --> membar(Assembler::LoadStore | >>>>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no comparable, >>>>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing LoadStore, >>>>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing LoadStore, >>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC operations >>>>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>>>> I need an additional optimization that removes the lwsync. I >>>>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a comparable >>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() before the >>>>>>>>>>>>>>>> read >>>>>>>>>>>>>>>> is inefficient on platforms that have multiple-read-atomicity. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>>>> Else, David, how would you propose to implement this platform >>>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can not possibly answer to the necessary level of detail with a >>>>>>>>>>>>>>> few >>>>>>>>>>>>>>> moments thought. You are implying there is a problem here that >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why ppc is so >>>>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>>>> moment. The >>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>>>> requirements for >>>>>>>>>>>>>>> volatile accesses is if there are global visibility issues that >>>>>>>>>>>>>>> are not >>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers at the >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> would deal with that, not at the load. (This situation reminds me >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the use of >>>>>>>>>>>>>>> software >>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - but we >>>>>>>>>>>>>>> don't have >>>>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a couple of days >>>>>>>>>>>>>>> I will >>>>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be relevant, so >>>>>>>>>>>>>>>> it might >>>>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY instead >>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get rid of >>>>>>>>>>>>>>>> them). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>>>> I agree we should not change it in the ppc port. If you wish, I >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a reasonable >>>>>>>>>>>>>>>> way :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From what I understand what we see here is an attempt to >>>>>>>>>>>>>>>> fix an >>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so that the >>>>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 is to make >>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a fence() when >>>>>>>>>>>>>>>> doing the >>>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>>>> performance >>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the shared code >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> allow this solution to be implemented - even with PPC64_ONLY >>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to what I said >>>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be expressed using >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>>>> properties >>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not needed >>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>> given architecture then the implementation in OrderAccess should >>>>>>>>>>>>>>>> reduce >>>>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are not needed >>>>>>>>>>>>>>>> under >>>>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not change our >>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>> code for our platforms (please, do not change do_exits() now). >>>>>>>>>>>>>>>>> But may be it should be done using more general query which >>>>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part of the >>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this out >>>>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>>>> like this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing here? Are >>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that the JMM >>>>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>>>> From what I understand our ppc port is also affected. >>>>>>>>>>>>>>>>> David? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not need >>>>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>>>> // Add MemBarRelease for constructors which write >>>>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>>>> __________ __________ __________ __________ >>>>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Solution: This example requires multiple-copy-atomicity. This >>>>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed in the >>>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that volatile >>>>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>>>> written in constructors are visible before the reference gets >>>>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to us, >>>>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should >>>>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Thu Jan 23 08:02:23 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:02:23 +0000 Subject: hg: ppc-aix-port/jdk7u: 30 new changesets Message-ID: <20140123160224.54A1B626D0@hg.openjdk.java.net> Changeset: 2dc0faccfa1e Author: asaha Date: 2013-09-11 15:47 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/2dc0faccfa1e Merge ! .hgtags Changeset: 0c5ae7837ff5 Author: asaha Date: 2013-09-18 11:15 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/0c5ae7837ff5 Merge ! .hgtags Changeset: bdcd50ab61e5 Author: asaha Date: 2013-09-18 11:27 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/bdcd50ab61e5 Merge ! .hgtags Changeset: cc9a05c9ad5c Author: asaha Date: 2013-09-19 15:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/cc9a05c9ad5c Merge ! .hgtags Changeset: df2784aa1ab9 Author: asaha Date: 2013-09-24 10:51 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/df2784aa1ab9 Merge ! .hgtags Changeset: 7fd771847022 Author: asaha Date: 2013-09-26 11:22 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/7fd771847022 Merge ! .hgtags Changeset: 6a8e3930abcc Author: asaha Date: 2013-09-27 12:14 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/6a8e3930abcc Merge ! .hgtags Changeset: 8bc059902950 Author: asaha Date: 2013-09-27 13:15 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/8bc059902950 Merge ! .hgtags Changeset: 8f67f7a072c2 Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/8f67f7a072c2 Added tag jdk7u51-b00 for changeset f2479abad143 ! .hgtags Changeset: c5822e1d1baa Author: asaha Date: 2013-09-30 11:11 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/c5822e1d1baa Merge ! .hgtags Changeset: a9d80d729eb2 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/a9d80d729eb2 Added tag jdk7u51-b01 for changeset c5822e1d1baa ! .hgtags Changeset: f019ffa367c2 Author: asaha Date: 2013-10-08 11:41 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/f019ffa367c2 Merge ! .hgtags Changeset: f750621fb31b Author: asaha Date: 2013-10-09 09:47 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/f750621fb31b Merge ! .hgtags Changeset: dafd6c301c97 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/dafd6c301c97 Added tag jdk7u51-b02 for changeset f750621fb31b ! .hgtags Changeset: 8bc2f477bba4 Author: cl Date: 2013-10-15 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/8bc2f477bba4 Added tag jdk7u51-b03 for changeset dafd6c301c97 ! .hgtags Changeset: 1604b330bf96 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/1604b330bf96 Added tag jdk7u51-b04 for changeset 8bc2f477bba4 ! .hgtags Changeset: 15c531ebb19c Author: cl Date: 2013-10-29 09:08 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/15c531ebb19c Added tag jdk7u51-b05 for changeset 1604b330bf96 ! .hgtags Changeset: 75f0610e93bf Author: cl Date: 2013-11-05 10:57 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/75f0610e93bf Added tag jdk7u51-b06 for changeset 15c531ebb19c ! .hgtags Changeset: 467fc49c32dd Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/467fc49c32dd Added tag jdk7u51-b07 for changeset 75f0610e93bf ! .hgtags Changeset: 73ebe4e4f20e Author: cl Date: 2013-11-19 08:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/73ebe4e4f20e Added tag jdk7u51-b08 for changeset 467fc49c32dd ! .hgtags Changeset: 9868efbea429 Author: asaha Date: 2013-11-27 08:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/9868efbea429 Added tag jdk7u51-b09 for changeset 73ebe4e4f20e ! .hgtags Changeset: 573c4cfca7dd Author: katleman Date: 2013-12-04 10:10 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/573c4cfca7dd Added tag jdk7u51-b10 for changeset 9868efbea429 ! .hgtags Changeset: df53ec7eb789 Author: katleman Date: 2013-12-10 13:15 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/df53ec7eb789 Added tag jdk7u51-b11 for changeset 573c4cfca7dd ! .hgtags Changeset: 6c778574d873 Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/6c778574d873 Added tag jdk7u51-b12 for changeset df53ec7eb789 ! .hgtags Changeset: 05742477836c Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/05742477836c Added tag jdk7u45-b33 for changeset b73c006b5d81 ! .hgtags Changeset: d0d5badd77ab Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/d0d5badd77ab Added tag jdk7u45-b34 for changeset 05742477836c ! .hgtags Changeset: 8a0fb2a53d19 Author: asaha Date: 2013-12-17 10:59 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/8a0fb2a53d19 Merge ! .hgtags Changeset: d2eeac0235ed Author: katleman Date: 2013-12-19 09:00 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/d2eeac0235ed Added tag jdk7u51-b13 for changeset 6c778574d873 ! .hgtags Changeset: 626e76f127a4 Author: asaha Date: 2013-12-19 09:31 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/626e76f127a4 Merge ! .hgtags Changeset: 2a1e98e1abf5 Author: goetz Date: 2014-01-23 16:59 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/2a1e98e1abf5 merge ! .hgtags From goetz.lindenmaier at sap.com Thu Jan 23 08:03:41 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:03:41 +0000 Subject: hg: ppc-aix-port/jdk7u/corba: 43 new changesets Message-ID: <20140123160414.5C9E1626D1@hg.openjdk.java.net> Changeset: 59d790829419 Author: asaha Date: 2013-09-11 15:47 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/59d790829419 Merge ! .hgtags Changeset: 3832ff63e7fc Author: asaha Date: 2013-09-18 11:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/3832ff63e7fc Merge ! .hgtags Changeset: 3092a6420d0d Author: asaha Date: 2013-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/3092a6420d0d Merge ! .hgtags Changeset: e379f8068ea6 Author: asaha Date: 2013-09-19 15:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/e379f8068ea6 Merge ! .hgtags Changeset: 694aaf53fcc2 Author: asaha Date: 2013-09-24 10:52 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/694aaf53fcc2 Merge ! .hgtags Changeset: 0540b0b57ce4 Author: asaha Date: 2013-09-26 11:22 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/0540b0b57ce4 Merge ! .hgtags Changeset: fd88b48792ce Author: asaha Date: 2013-09-27 12:14 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/fd88b48792ce Merge ! .hgtags Changeset: bdd1f5afad32 Author: asaha Date: 2013-09-27 13:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/bdd1f5afad32 Merge ! .hgtags Changeset: 419d784bf801 Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/419d784bf801 Added tag jdk7u51-b00 for changeset b1f069eb48ed ! .hgtags Changeset: 8d884cf2e8cc Author: asaha Date: 2013-09-30 11:11 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/8d884cf2e8cc Merge ! .hgtags Changeset: 8ce0ac5270b8 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/8ce0ac5270b8 Added tag jdk7u51-b01 for changeset 8d884cf2e8cc ! .hgtags Changeset: d927facb63bc Author: asaha Date: 2013-10-08 11:42 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/d927facb63bc Merge ! .hgtags Changeset: 327035fbb043 Author: asaha Date: 2013-10-09 09:49 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/327035fbb043 Merge ! .hgtags Changeset: 3c186a6d2b86 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/3c186a6d2b86 Added tag jdk7u51-b02 for changeset 327035fbb043 ! .hgtags Changeset: 6969598640b2 Author: cl Date: 2013-10-15 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/6969598640b2 Added tag jdk7u51-b03 for changeset 3c186a6d2b86 ! .hgtags Changeset: b18c17608d94 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/b18c17608d94 Added tag jdk7u51-b04 for changeset 6969598640b2 ! .hgtags Changeset: 1c997cdaf0f8 Author: cl Date: 2013-10-29 09:08 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/1c997cdaf0f8 Added tag jdk7u51-b05 for changeset b18c17608d94 ! .hgtags Changeset: d39d92c2cab1 Author: alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/d39d92c2cab1 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java Changeset: 863d69d3dee0 Author: asaha Date: 2013-11-04 10:58 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/863d69d3dee0 Merge Changeset: 8f9d49f7e74c Author: cl Date: 2013-11-05 10:57 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/8f9d49f7e74c Added tag jdk7u51-b06 for changeset 863d69d3dee0 ! .hgtags Changeset: 77d13acb85bf Author: asaha Date: 2013-10-29 09:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/77d13acb85bf Merge Changeset: b1548473f261 Author: msheppar Date: 2013-11-02 01:07 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/b1548473f261 8026193: Enhance CORBA stub factories Summary: modify com.sun.corba.se.impl.presenetation.rmi.StubFactoryDynamicBase inheritance structure. Reviewed-by: alanb, coffeys, ahgross ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryFactoryProxyImpl.java Changeset: 0a879f00b698 Author: msheppar Date: 2013-11-02 01:24 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/0a879f00b698 8025767: Enhance IIOP Streams Summary: modify org.omg.CORBA_2_3.portable.InputStream inheritance structure. Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsOutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeOutputStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/CDREncapsCodec.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/SharedCDRClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java ! src/share/classes/com/sun/corba/se/spi/servicecontext/ServiceContexts.java ! src/share/classes/org/omg/CORBA_2_3/portable/InputStream.java + src/share/classes/sun/corba/EncapsInputStreamFactory.java Changeset: 880cc2c3ba33 Author: asaha Date: 2013-11-05 12:03 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/880cc2c3ba33 Merge Changeset: 3910fba40bac Author: mfang Date: 2013-11-07 12:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/3910fba40bac 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp Changeset: 4baf8650e2c5 Author: mfang Date: 2013-11-07 12:50 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/4baf8650e2c5 Merge Changeset: 3f6dfcad33ac Author: coffeys Date: 2013-11-11 15:52 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/3f6dfcad33ac 8027837: JDK-8021257 causes CORBA build failure on emdedded platforms Reviewed-by: dholmes ! make/Makefile Changeset: 652dbc49eb47 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/652dbc49eb47 Added tag jdk7u51-b07 for changeset 3f6dfcad33ac ! .hgtags Changeset: 8ce01c9da345 Author: mchung Date: 2013-11-07 20:48 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/8ce01c9da345 8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45 Reviewed-by: msheppar, alanb, lancea ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: 2ef8307ce38d Author: coffeys Date: 2013-11-11 15:52 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/2ef8307ce38d 8027837: JDK-8021257 causes CORBA build failure on emdedded platforms Reviewed-by: dholmes ! make/Makefile Changeset: 00c7d4007a2f Author: asaha Date: 2013-11-12 09:10 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/00c7d4007a2f Merge Changeset: 07177000db8f Author: cl Date: 2013-11-19 08:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/07177000db8f Added tag jdk7u51-b08 for changeset 00c7d4007a2f ! .hgtags Changeset: bb45667f58f5 Author: msheppar Date: 2013-11-24 13:09 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/bb45667f58f5 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung ! src/share/classes/org/omg/CORBA/ORB.java Changeset: eecfc296009b Author: asaha Date: 2013-11-27 08:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/eecfc296009b Added tag jdk7u51-b09 for changeset bb45667f58f5 ! .hgtags Changeset: a26d0e8ab102 Author: katleman Date: 2013-12-04 10:10 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/a26d0e8ab102 Added tag jdk7u51-b10 for changeset eecfc296009b ! .hgtags Changeset: 55a509ccc0e4 Author: katleman Date: 2013-12-10 13:15 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/55a509ccc0e4 Added tag jdk7u51-b11 for changeset a26d0e8ab102 ! .hgtags Changeset: e2f0036f712a Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/e2f0036f712a Added tag jdk7u51-b12 for changeset 55a509ccc0e4 ! .hgtags Changeset: aa24e046a2da Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/aa24e046a2da Added tag jdk7u45-b33 for changeset d641ac83157e ! .hgtags Changeset: fab1423e6ab8 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/fab1423e6ab8 Added tag jdk7u45-b34 for changeset aa24e046a2da ! .hgtags Changeset: bdfd3d51d3c9 Author: asaha Date: 2013-12-17 11:01 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/bdfd3d51d3c9 Merge ! .hgtags Changeset: 6563d12c48c9 Author: katleman Date: 2013-12-19 09:00 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/6563d12c48c9 Added tag jdk7u51-b13 for changeset e2f0036f712a ! .hgtags Changeset: 0ad990211737 Author: asaha Date: 2013-12-19 09:31 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/0ad990211737 Merge ! .hgtags Changeset: fa491237c578 Author: goetz Date: 2014-01-23 16:59 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/fa491237c578 merge ! .hgtags From goetz.lindenmaier at sap.com Thu Jan 23 08:06:18 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:06:18 +0000 Subject: hg: ppc-aix-port/jdk7u/jaxws: 37 new changesets Message-ID: <20140123160744.0D6B2626D4@hg.openjdk.java.net> Changeset: 39ff85cc715a Author: asaha Date: 2013-09-12 08:10 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/39ff85cc715a Merge ! .hgtags Changeset: 59955e1a7dd9 Author: asaha Date: 2013-09-18 11:18 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/59955e1a7dd9 Merge ! .hgtags Changeset: e08f65847031 Author: asaha Date: 2013-09-18 11:33 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/e08f65847031 Merge ! .hgtags Changeset: abc0a1824ac1 Author: asaha Date: 2013-09-19 15:33 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/abc0a1824ac1 Merge ! .hgtags Changeset: f872a2c20c73 Author: asaha Date: 2013-09-24 10:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/f872a2c20c73 Merge ! .hgtags Changeset: c89fb333a433 Author: asaha Date: 2013-09-26 11:25 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/c89fb333a433 Merge ! .hgtags Changeset: 789accb40535 Author: asaha Date: 2013-09-27 12:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/789accb40535 Merge ! .hgtags Changeset: 633d2b660dc7 Author: asaha Date: 2013-09-27 13:17 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/633d2b660dc7 Merge ! .hgtags Changeset: abb36d7905e1 Author: asaha Date: 2013-09-30 11:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/abb36d7905e1 Added tag jdk7u51-b00 for changeset 5524cced32d3 ! .hgtags Changeset: db9e3328f393 Author: asaha Date: 2013-09-30 11:14 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/db9e3328f393 Merge ! .hgtags Changeset: 37c05268d345 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/37c05268d345 Added tag jdk7u51-b01 for changeset db9e3328f393 ! .hgtags Changeset: 33b208594508 Author: asaha Date: 2013-10-08 11:55 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/33b208594508 Merge ! .hgtags Changeset: 92a4787cb361 Author: asaha Date: 2013-10-09 09:55 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/92a4787cb361 Merge ! .hgtags Changeset: 2240523feb96 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/2240523feb96 Added tag jdk7u51-b02 for changeset 92a4787cb361 ! .hgtags Changeset: 50eb8741c48b Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/50eb8741c48b Added tag jdk7u51-b03 for changeset 2240523feb96 ! .hgtags Changeset: d2c4d2c9fc71 Author: mkos Date: 2013-10-16 10:23 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/d2c4d2c9fc71 8010935: Better XML handling Reviewed-by: mchung, mgrebac, mullan ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/APTNavigator.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/JAXBRIContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/TypeReference.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java Changeset: 74ebb62c1324 Author: mullan Date: 2013-10-16 10:26 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/74ebb62c1324 Merge Changeset: c4f7cc35e47a Author: mullan Date: 2013-10-17 17:37 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/c4f7cc35e47a 8026826: JDK 7 fix for 8010935 broke the build Reviewed-by: prr + src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/ws/model/Utils.java Changeset: f8f0617c0310 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/f8f0617c0310 Added tag jdk7u51-b04 for changeset c4f7cc35e47a ! .hgtags Changeset: 49fc29e8890c Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/49fc29e8890c Added tag jdk7u51-b05 for changeset f8f0617c0310 ! .hgtags Changeset: f6dd9063f3b3 Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/f6dd9063f3b3 Added tag jdk7u51-b06 for changeset 49fc29e8890c ! .hgtags Changeset: b0ef08d5e517 Author: mkos Date: 2013-11-08 20:15 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/b0ef08d5e517 8027224: test regression - ClassNotFoundException Summary: test regression; fix also reviewed by Filipp Zkinkin, Iaroslav Savytskyi, Alexander Fomin Reviewed-by: mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java Changeset: c3a650bee848 Author: mkos Date: 2013-11-09 10:15 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/c3a650bee848 8028090: reverting change - changeset pushed with incorrect commit message, linked to wrong issue Reviewed-by: asaha ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java Changeset: da128632f015 Author: mkos Date: 2013-11-09 10:19 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/da128632f015 8027378: Two closed/javax/xml/8005432 fails with jdk7u51b04 Summary: test regression; fix also reviewed by Maxim Soloviev, Alexander Fomin Reviewed-by: mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java Changeset: 71a314d55844 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/71a314d55844 Added tag jdk7u51-b07 for changeset da128632f015 ! .hgtags Changeset: 1d160e2b9f7b Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/1d160e2b9f7b Added tag jdk7u51-b08 for changeset 71a314d55844 ! .hgtags Changeset: 3b53d5ea0aec Author: mkos Date: 2013-11-21 11:15 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/3b53d5ea0aec 8028382: Two javax/xml/8005433 tests still fail after the fix JDK-8028147 Summary: test regression; fix also reviewed by Iaroslav Savytskyi, Alexander Fomin Reviewed-by: mchung ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java Changeset: 53a566a724e5 Author: asaha Date: 2013-11-27 08:22 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/53a566a724e5 Added tag jdk7u51-b09 for changeset 3b53d5ea0aec ! .hgtags Changeset: 708507f4795c Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/708507f4795c Added tag jdk7u51-b10 for changeset 53a566a724e5 ! .hgtags Changeset: 7c7c2ea4b680 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/7c7c2ea4b680 Added tag jdk7u51-b11 for changeset 708507f4795c ! .hgtags Changeset: 81a1b110f70c Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/81a1b110f70c Added tag jdk7u51-b12 for changeset 7c7c2ea4b680 ! .hgtags Changeset: e7df5d6b23c6 Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/e7df5d6b23c6 Added tag jdk7u45-b33 for changeset e040abab3625 ! .hgtags Changeset: c654ba4b2392 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/c654ba4b2392 Added tag jdk7u45-b34 for changeset e7df5d6b23c6 ! .hgtags Changeset: 6f9e7eece4ff Author: asaha Date: 2013-12-17 11:13 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/6f9e7eece4ff Merge ! .hgtags Changeset: 5dbeb9983f10 Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/5dbeb9983f10 Added tag jdk7u51-b13 for changeset 81a1b110f70c ! .hgtags Changeset: eb79f394916e Author: asaha Date: 2013-12-19 09:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/eb79f394916e Merge ! .hgtags Changeset: 919c657684b6 Author: goetz Date: 2014-01-23 17:00 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/919c657684b6 merge ! .hgtags ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java From goetz.lindenmaier at sap.com Thu Jan 23 08:08:28 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:08:28 +0000 Subject: hg: ppc-aix-port/jdk7u/langtools: 32 new changesets Message-ID: <20140123160938.0DEE0626D5@hg.openjdk.java.net> Changeset: 591b0e947c04 Author: asaha Date: 2013-09-12 08:13 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/591b0e947c04 Merge ! .hgtags Changeset: 058d55941249 Author: asaha Date: 2013-09-18 11:21 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/058d55941249 Merge ! .hgtags Changeset: 7e9fe0a89f90 Author: asaha Date: 2013-09-18 11:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/7e9fe0a89f90 Merge ! .hgtags Changeset: 83fcd22f90e4 Author: asaha Date: 2013-09-19 15:33 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/83fcd22f90e4 Merge ! .hgtags Changeset: 083ce047cf94 Author: asaha Date: 2013-09-24 10:55 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/083ce047cf94 Merge ! .hgtags Changeset: b1295b13534f Author: asaha Date: 2013-09-26 11:26 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/b1295b13534f Merge ! .hgtags Changeset: f8576d750234 Author: asaha Date: 2013-09-27 12:18 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/f8576d750234 Merge ! .hgtags Changeset: e4db78716919 Author: asaha Date: 2013-09-27 13:18 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/e4db78716919 Merge ! .hgtags Changeset: 5e8ed6530196 Author: asaha Date: 2013-09-30 11:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/5e8ed6530196 Added tag jdk7u51-b00 for changeset 18d1864abca9 ! .hgtags Changeset: 14d1cf2630ae Author: asaha Date: 2013-09-30 11:15 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/14d1cf2630ae Merge ! .hgtags Changeset: 91fd49745ba1 Author: cl Date: 2013-10-01 08:37 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/91fd49745ba1 Added tag jdk7u51-b01 for changeset 14d1cf2630ae ! .hgtags Changeset: 13cf4886911f Author: asaha Date: 2013-10-08 12:01 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/13cf4886911f Merge ! .hgtags Changeset: f0168ccf171e Author: asaha Date: 2013-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/f0168ccf171e Merge ! .hgtags Changeset: 33f986894a3e Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/33f986894a3e Added tag jdk7u51-b02 for changeset f0168ccf171e ! .hgtags Changeset: 9a4b7362a592 Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/9a4b7362a592 Added tag jdk7u51-b03 for changeset 33f986894a3e ! .hgtags Changeset: c8d1379f16eb Author: cl Date: 2013-10-22 22:24 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/c8d1379f16eb Added tag jdk7u51-b04 for changeset 9a4b7362a592 ! .hgtags Changeset: 1e8c8518497b Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/1e8c8518497b Added tag jdk7u51-b05 for changeset c8d1379f16eb ! .hgtags Changeset: 253a82945c71 Author: cl Date: 2013-11-05 10:59 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/253a82945c71 Added tag jdk7u51-b06 for changeset 1e8c8518497b ! .hgtags Changeset: 60d5dc8c5c8c Author: mfang Date: 2013-11-07 12:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/60d5dc8c5c8c 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties Changeset: 009a4086b2a6 Author: mfang Date: 2013-11-07 12:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/009a4086b2a6 Merge Changeset: cccd0d52003d Author: cl Date: 2013-11-12 08:52 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/cccd0d52003d Added tag jdk7u51-b07 for changeset 009a4086b2a6 ! .hgtags Changeset: d8a69a841acd Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/d8a69a841acd Added tag jdk7u51-b08 for changeset cccd0d52003d ! .hgtags Changeset: 7e33fc6adc82 Author: asaha Date: 2013-11-27 08:26 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/7e33fc6adc82 Added tag jdk7u51-b09 for changeset d8a69a841acd ! .hgtags Changeset: c9d8d8793d93 Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/c9d8d8793d93 Added tag jdk7u51-b10 for changeset 7e33fc6adc82 ! .hgtags Changeset: 5b44df2114e4 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/5b44df2114e4 Added tag jdk7u51-b11 for changeset c9d8d8793d93 ! .hgtags Changeset: 4d0807934c30 Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/4d0807934c30 Added tag jdk7u51-b12 for changeset 5b44df2114e4 ! .hgtags Changeset: bcb3e939d046 Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/bcb3e939d046 Added tag jdk7u45-b33 for changeset ef7bdbe7f1fa ! .hgtags Changeset: efbda7abd821 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/efbda7abd821 Added tag jdk7u45-b34 for changeset bcb3e939d046 ! .hgtags Changeset: 96d897736590 Author: asaha Date: 2013-12-17 11:20 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/96d897736590 Merge ! .hgtags Changeset: ada23e55d76a Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/ada23e55d76a Added tag jdk7u51-b13 for changeset 4d0807934c30 ! .hgtags Changeset: e3d4896d52ab Author: asaha Date: 2013-12-19 09:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/e3d4896d52ab Merge ! .hgtags Changeset: 37fca9892869 Author: goetz Date: 2014-01-23 17:00 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/37fca9892869 merge ! .hgtags From goetz.lindenmaier at sap.com Thu Jan 23 08:10:22 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:10:22 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: 36 new changesets Message-ID: <20140123161159.09BEB626D6@hg.openjdk.java.net> Changeset: ca681a7f3a26 Author: asaha Date: 2013-09-12 08:08 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/ca681a7f3a26 Merge ! .hgtags ! make/hotspot_version Changeset: 962bde0be11c Author: coleenp Date: 2013-09-16 14:22 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/962bde0be11c 8021271: Better buffering in ObjC code Summary: Improve buffering in ObjC code Reviewed-by: serb, hseigel, coleenp Contributed-by: gerard.ziemski at oracle.com ! src/share/vm/runtime/os.cpp Changeset: 143a99671e52 Author: asaha Date: 2013-09-18 11:17 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/143a99671e52 Merge ! .hgtags Changeset: af92fd5e046e Author: asaha Date: 2013-09-18 11:30 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/af92fd5e046e Merge ! .hgtags Changeset: ab8db063dccc Author: asaha Date: 2013-09-19 15:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/ab8db063dccc Merge ! .hgtags Changeset: 8e077c93ab9a Author: asaha Date: 2013-09-24 10:52 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/8e077c93ab9a Merge ! .hgtags Changeset: 129a5092d628 Author: asaha Date: 2013-09-26 11:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/129a5092d628 Merge ! .hgtags Changeset: 0d4045749f28 Author: asaha Date: 2013-09-27 12:15 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/0d4045749f28 Merge ! .hgtags Changeset: 45820ef2222f Author: asaha Date: 2013-09-27 13:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/45820ef2222f Merge ! .hgtags Changeset: fa74e40ea420 Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/fa74e40ea420 Added tag jdk7u51-b00 for changeset 429884602206 ! .hgtags Changeset: a9dcf7edc696 Author: asaha Date: 2013-09-30 11:12 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/a9dcf7edc696 Merge ! .hgtags Changeset: 68f03ff066f2 Author: asaha Date: 2013-09-30 11:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/68f03ff066f2 8025679: Increment minor version of HSx for 7u51 and initialize the build number Reviewed-by: jcoomes ! make/hotspot_version Changeset: 68c42e105b90 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/68c42e105b90 Added tag jdk7u51-b01 for changeset 68f03ff066f2 ! .hgtags Changeset: 050690eaebec Author: asaha Date: 2013-10-08 11:49 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/050690eaebec Merge ! .hgtags Changeset: 67910a581eca Author: asaha Date: 2013-10-09 09:50 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/67910a581eca Merge ! .hgtags Changeset: 4138fb11955a Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/4138fb11955a Added tag jdk7u51-b02 for changeset 67910a581eca ! .hgtags Changeset: 683458c333ce Author: cl Date: 2013-10-15 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/683458c333ce Added tag jdk7u51-b03 for changeset 4138fb11955a ! .hgtags Changeset: ed2db7a82229 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/ed2db7a82229 Added tag jdk7u51-b04 for changeset 683458c333ce ! .hgtags Changeset: fec027762cf3 Author: cl Date: 2013-10-29 09:08 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/fec027762cf3 Added tag jdk7u51-b05 for changeset ed2db7a82229 ! .hgtags Changeset: 18c14aa176b3 Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/18c14aa176b3 Added tag jdk7u51-b06 for changeset fec027762cf3 ! .hgtags Changeset: eb486a2ec09b Author: asaha Date: 2013-11-06 14:47 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/eb486a2ec09b 8027944: Increment hsx 24.51 build to b02 for 7u51-b07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f673c581ebf9 Author: aeriksso Date: 2013-10-31 16:49 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/f673c581ebf9 8026887: Make issues due to failed large pages allocations easier to debug Reviewed-by: stefank, mcastegr, poonam ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/share/vm/utilities/vmError.cpp Changeset: b0a355aae004 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b0a355aae004 Added tag jdk7u51-b07 for changeset f673c581ebf9 ! .hgtags Changeset: 4f56f2e206fd Author: cl Date: 2013-11-19 08:36 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/4f56f2e206fd Added tag jdk7u51-b08 for changeset b0a355aae004 ! .hgtags Changeset: 1b7aaef3df78 Author: asaha Date: 2013-11-27 08:20 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1b7aaef3df78 Added tag jdk7u51-b09 for changeset 4f56f2e206fd ! .hgtags Changeset: 0cff26632b96 Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/0cff26632b96 Added tag jdk7u51-b10 for changeset 1b7aaef3df78 ! .hgtags Changeset: 839100e42498 Author: jrose Date: 2013-12-05 14:38 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/839100e42498 8029507: Enhance JVM method processing 8029533: REGRESSION: closed/java/lang/invoke/8008140/Test8008140.java fails against JPRT PIT 17891982 build 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName Reviewed-by: acorn, vlivanov ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 1f11dff734af Author: asaha Date: 2013-12-09 13:55 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1f11dff734af 8029842: Increment hsx 24.51 build to b03 for 7u51-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: dee2a38ef6b2 Author: katleman Date: 2013-12-10 13:15 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/dee2a38ef6b2 Added tag jdk7u51-b11 for changeset 1f11dff734af ! .hgtags Changeset: 6c6a2299029a Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/6c6a2299029a Added tag jdk7u51-b12 for changeset dee2a38ef6b2 ! .hgtags Changeset: 0bcb43482f2a Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/0bcb43482f2a Added tag jdk7u45-b33 for changeset c373a733d5d5 ! .hgtags Changeset: 12ea8d416f10 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/12ea8d416f10 Added tag jdk7u45-b34 for changeset 0bcb43482f2a ! .hgtags Changeset: d9ac18d080af Author: asaha Date: 2013-12-17 11:06 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/d9ac18d080af Merge ! .hgtags Changeset: a398ddc79d23 Author: katleman Date: 2013-12-19 09:00 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/a398ddc79d23 Added tag jdk7u51-b13 for changeset 6c6a2299029a ! .hgtags Changeset: cf4110c35afb Author: asaha Date: 2013-12-19 09:32 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/cf4110c35afb Merge ! .hgtags Changeset: 250a2b89aae6 Author: goetz Date: 2014-01-23 17:00 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/250a2b89aae6 merge ! .hgtags ! make/hotspot_version ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/vmError.cpp From goetz.lindenmaier at sap.com Thu Jan 23 08:03:39 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:03:39 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: 82 new changesets Message-ID: <20140123161955.89076626E0@hg.openjdk.java.net> Changeset: 050746671449 Author: lancea Date: 2013-08-15 11:46 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/050746671449 8022904: Enhance JDBC Parsers Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: d6d233ee9422 Author: weijun Date: 2013-08-17 06:51 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/d6d233ee9422 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: c0ff56eaaa96 Author: chegar Date: 2013-08-09 13:50 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/c0ff56eaaa96 8022661: InetAddress.writeObject() performs flush() on object output stream Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java Changeset: 4b7df9a8efc3 Author: weijun Date: 2013-08-19 22:43 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/4b7df9a8efc3 8022945: Enhance JNDI implementation classes Reviewed-by: xuelei, ahgross, skoivu ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: f43bc2c60d21 Author: erikj Date: 2013-08-19 17:51 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/f43bc2c60d21 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/bridge/Jabswitch/Makefile Changeset: 9305237ab3d4 Author: asaha Date: 2013-08-20 10:51 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/9305237ab3d4 Merge Changeset: c7cf5b83f7dd Author: valeriep Date: 2013-08-21 12:07 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/c7cf5b83f7dd 8022927: Input validation for byte/endian conversions Summary: Add additional boundary checks Reviewed-by: ascarpino ! src/share/classes/sun/security/provider/ByteArrayAccess.java Changeset: 3d00b699d5d2 Author: asaha Date: 2013-08-22 08:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/3d00b699d5d2 Merge Changeset: 995b32f013f5 Author: malenkov Date: 2013-09-02 16:56 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/995b32f013f5 8023245: Enhance Beans decoding Reviewed-by: art, skoivu, alanb ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: fd6170becf78 Author: asaha Date: 2013-08-27 15:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/fd6170becf78 Merge Changeset: ddd59bc77e60 Author: asaha Date: 2013-09-04 08:30 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/ddd59bc77e60 Merge Changeset: 30e41fbd2e24 Author: asaha Date: 2013-09-04 12:29 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/30e41fbd2e24 Merge Changeset: d533e96c7acc Author: xuelei Date: 2013-09-05 18:17 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/d533e96c7acc 8023069: Enhance TLS connections Summary: Also reviewed by Alexander Fomin and Andrew Gross Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/rsa/RSAPadding.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 1b998b8306b9 Author: sherman Date: 2013-09-10 15:39 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/1b998b8306b9 8022868: missing codepage Cp290 at java runtime Summary: to add cp290 and cp300 Reviewed-by: alanb, coffeys + make/tools/CharsetMapping/IBM290.c2b + make/tools/CharsetMapping/IBM290.map ! make/tools/CharsetMapping/extsbcs ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/IBM300.java Changeset: eac032b93d19 Author: asaha Date: 2013-09-11 15:33 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/eac032b93d19 Merge Changeset: a5a90a118ce0 Author: asaha Date: 2013-09-12 08:11 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/a5a90a118ce0 Merge ! .hgtags Changeset: 41dc340af6aa Author: sherman Date: 2013-09-12 14:41 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/41dc340af6aa 8024668: api/java_nio/charset/Charset/index.html#Methods JCK-runtime test fails with 7u45 b11 Summary: to add IBM290 into make/sun/nio/cs/FILES_java.gmk Reviewed-by: alanb, coffeys ! make/sun/nio/cs/FILES_java.gmk Changeset: abe1cb2d27cb Author: weijun Date: 2013-09-13 15:17 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/abe1cb2d27cb 8024306: Enhance Subject consistency Summary: Also reviewed by Alexander Fomin Reviewed-by: mullan, ahgross ! src/share/classes/javax/security/auth/Subject.java Changeset: d5f36e1c927e Author: weijun Date: 2013-09-13 15:22 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/d5f36e1c927e 8023672: Enhance jar file validation Summary: Also reviewed by Chris Ries and Alexander Fomin Reviewed-by: mullan, sherman ! src/share/classes/java/util/jar/JarVerifier.java Changeset: 1a975041e36e Author: vadim Date: 2013-09-13 12:52 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/1a975041e36e 8023057: Enhance start up image display Reviewed-by: anthony, serb, mschoene ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/share/native/sun/awt/splashscreen/splashscreen_impl.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: f4737bbf6ca7 Author: bae Date: 2013-09-13 19:19 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/f4737bbf6ca7 8024697: Fix for 8020983 causes Xcheck:jni warnings Reviewed-by: prr, jchen ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java Changeset: 089e3a70de1d Author: coleenp Date: 2013-09-16 14:22 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/089e3a70de1d 8021271: Better buffering in ObjC code Summary: Improve buffering in ObjC code Reviewed-by: serb, hseigel, coleenp Contributed-by: gerard.ziemski at oracle.com ! make/common/Release.gmk ! make/java/Makefile Changeset: 77f5558b5215 Author: erikj Date: 2013-09-19 13:32 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/77f5558b5215 8023771: when USER_RELEASE_SUFFIX is set in order to add a string to java -version, build number in the bundles names should not be changed to b00 Reviewed-by: dholmes, ihse ! make/common/shared/Defs.gmk Changeset: 9d29c19f1de1 Author: vadim Date: 2013-09-19 20:56 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/9d29c19f1de1 8025034: Improve layout lookups Reviewed-by: mschoene, vadim, srl ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: b85c94444634 Author: erikj Date: 2013-09-23 17:38 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/b85c94444634 8025170: jdk7u51 7u-1-prebuild is failing since 9/19 Reviewed-by: tbell, ihse ! make/common/shared/Defs.gmk Changeset: 627abacf40db Author: asaha Date: 2013-09-30 11:45 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/627abacf40db Merge ! .hgtags Changeset: 2e35e0dbd2b6 Author: asaha Date: 2013-09-30 11:45 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/2e35e0dbd2b6 Added tag jdk7u51-b00 for changeset 3c9a6d9eafd3 + .hgtags Changeset: 48e447472911 Author: asaha Date: 2013-09-30 11:51 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/48e447472911 Merge ! .hgtags Changeset: d76613074ff3 Author: asaha Date: 2013-09-30 11:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/d76613074ff3 Merge ! .hgtags Changeset: 4ef9342e2599 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/4ef9342e2599 Added tag jdk7u51-b01 for changeset d76613074ff3 ! .hgtags Changeset: 7f2fc6c7c6dd Author: weijun Date: 2013-09-19 10:40 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/7f2fc6c7c6dd 8024302: Clarify jar verifications 8023338: Update jarsigner to encourage timestamping Reviewed-by: mullan, ahgross ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ts.sh + test/sun/security/tools/jarsigner/warnings.sh Changeset: dc04e86b0dac Author: malenkov Date: 2013-10-04 19:39 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/dc04e86b0dac 8025448: Enhance listening events Reviewed-by: art, skoivu ! src/share/classes/javax/swing/event/EventListenerList.java Changeset: 15c242aefefd Author: dfuchs Date: 2013-10-07 12:09 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/15c242aefefd 8024867: Enhance logging start up Reviewed-by: mchung, hawtin ! src/share/classes/java/util/logging/LogManager.java Changeset: 35644fe4a796 Author: weijun Date: 2013-10-09 18:58 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/35644fe4a796 8026037: [TESTBUG] sun/security/tools/jarsigner/warnings.sh test fails on Solaris Reviewed-by: chegar Contributed-by: Artem Smotrakov ! test/sun/security/tools/jarsigner/warnings.sh Changeset: fb057871f094 Author: asaha Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/fb057871f094 Merge ! .hgtags Changeset: 6be222726f6d Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/6be222726f6d Added tag jdk7u51-b02 for changeset fb057871f094 ! .hgtags Changeset: 8e542d28b8ec Author: jfranck Date: 2013-10-11 11:22 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/8e542d28b8ec 8023301: Enhance generic classes Reviewed-by: mchung, hawtin ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 9fbac37835f2 Author: weijun Date: 2013-10-12 10:22 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/9fbac37835f2 8026304: jarsigner output bad grammar Reviewed-by: chegar, coffeys Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/tools/JarSignerResources.java Changeset: 232d21f4de76 Author: mcherkas Date: 2013-10-03 17:32 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/232d21f4de76 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: alexp, malenkov ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 6b3c195c73b0 Author: xuelei Date: 2013-10-14 18:35 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/6b3c195c73b0 8025026: Enhance canonicalization Summary: Don't use cached null xmlns definition. Also reviewed by Alexander Fomin Reviewed-by: mullan, hawtin ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: 0797c957fdb9 Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/0797c957fdb9 Added tag jdk7u51-b03 for changeset 6b3c195c73b0 ! .hgtags Changeset: aef5cd4ac081 Author: prr Date: 2013-10-15 11:34 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/aef5cd4ac081 8026176: Enhance document printing Reviewed-by: bae, jgodinez ! src/share/classes/javax/print/SimpleDoc.java Changeset: 2197764aee8b Author: xuelei Date: 2013-10-15 20:15 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/2197764aee8b 8026204: Enhance auth login contexts Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: cd8026b9d403 Author: malenkov Date: 2013-10-16 14:02 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/cd8026b9d403 8026172: Enhance UI Management Reviewed-by: art, skoivu ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 5c20ac773584 Author: xuelei Date: 2013-10-16 20:12 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5c20ac773584 8025758: Enhance Naming management Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java Changeset: dd60bcc30d64 Author: jchen Date: 2013-10-16 15:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/dd60bcc30d64 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test Reviewed-by: prr, vadim, serb ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c Changeset: ac44ec0de12a Author: prr Date: 2013-10-20 06:12 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/ac44ec0de12a 8024530: Enhance font process resilience Reviewed-by: mschoene, bae, srl, prr ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/TibetanReordering.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: 496c51673dec Author: sjiang Date: 2013-10-21 17:47 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/496c51673dec 7068126: Enhance SNMP statuses Reviewed-by: dfuchs, hawtin ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java Changeset: 5348ecf3da7f Author: weijun Date: 2013-10-17 09:58 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5348ecf3da7f 8025014: Enhance Security Policy 6727821: Enhance JAAS Configuration Reviewed-by: xuelei, hawtin ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: cd2808b7e276 Author: xuelei Date: 2013-07-29 19:02 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/cd2808b7e276 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/util/KeyUtil.java + test/com/sun/crypto/provider/TLS/TestLeadingZeroes.java + test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java Changeset: 96431826ae3a Author: coffeys Date: 2013-10-22 09:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/96431826ae3a Merge Changeset: 3fd08b034937 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/3fd08b034937 Added tag jdk7u51-b04 for changeset 96431826ae3a ! .hgtags Changeset: 8ee582bb96a6 Author: xuelei Date: 2013-10-24 10:07 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/8ee582bb96a6 8027204: Revise the update of 8026204 and 8025758 Summary: Rivise the update to use system class loader with null TCCL. Also reviewed by Alexander Fomin Reviewed-by: weijun, mchung, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: ec12a8266386 Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/ec12a8266386 Added tag jdk7u51-b05 for changeset 8ee582bb96a6 ! .hgtags Changeset: 07004bb53c3c Author: xuelei Date: 2013-10-23 21:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/07004bb53c3c 8026417: Enhance XML canonicalization Summary: Copy before use mutable byte arrays. Also reviewed by Alexander Fomin Reviewed-by: weijun, mullan, hawtin, ahgross ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: 8a60b069f9cd Author: asaha Date: 2013-10-31 14:40 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/8a60b069f9cd Merge Changeset: 8afbbdc15c3c Author: kshefov Date: 2013-06-21 17:53 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/8afbbdc15c3c 8015976: OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions Reviewed-by: coffeys, alanb ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java ! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java Changeset: 32842dd53611 Author: aefimov Date: 2013-10-24 17:14 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/32842dd53611 8025255: (tz) Support tzdata2013g 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! test/ProblemList.txt ! test/sun/util/resources/TimeZone/Bug6317929.java Changeset: 594ae80153af Author: alanb Date: 2013-10-24 19:21 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/594ae80153af 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oracle.com, mark.sheppard at oracle.com ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 982700bf473b Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/982700bf473b Added tag jdk7u51-b06 for changeset 594ae80153af ! .hgtags Changeset: 9b3b76f0b195 Author: mfang Date: 2013-11-07 12:20 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/9b3b76f0b195 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/linux/doc/man/ja/jarsigner.1 ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 Changeset: 7b84e6514c29 Author: rgallard Date: 2013-11-08 13:50 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/7b84e6514c29 8028057: Modify jarsigner man page documentation to document CCC 8024302: Clarify jar verifications Reviewed-by: weijun ! src/bsd/doc/man/jarsigner.1 ! src/linux/doc/man/jarsigner.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 Changeset: 40fca6b57cd8 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/40fca6b57cd8 Added tag jdk7u51-b07 for changeset 7b84e6514c29 ! .hgtags Changeset: 9afd02dabdf9 Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/9afd02dabdf9 Added tag jdk7u51-b08 for changeset 40fca6b57cd8 ! .hgtags Changeset: 909ea1f47e0b Author: coffeys Date: 2013-11-21 13:39 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/909ea1f47e0b 8022698: javax/script/GetInterfaceTest.java fails since 7u45 b04 with -agentvm option Reviewed-by: sundar ! test/javax/script/GetInterfaceTest.java Changeset: e6160aedadd5 Author: michaelm Date: 2013-11-01 10:40 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/e6160aedadd5 8011786: Better applet networking Summary: add checkListen() to client socket binds and new interpretation for port number 0 in SocketPermission Reviewed-by: chegar, alanb ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/lib/security/java.policy ! 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 ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java Changeset: 2bce3c0856af Author: michaelm Date: 2013-11-20 15:28 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/2bce3c0856af 8028453: AsynchronousSocketChannel.connect() requires SocketPermission due to bind to local address (win) Reviewed-by: alanb, chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Changeset: 33ae35eeb5a4 Author: msheppar Date: 2013-11-24 13:08 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/33ae35eeb5a4 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung + test/com/sun/corba/se/impl/orb/SetDefaultORBTest.java Changeset: 216138d587a7 Author: asaha Date: 2013-11-27 08:24 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/216138d587a7 Added tag jdk7u51-b09 for changeset 33ae35eeb5a4 ! .hgtags Changeset: e935cd4139c6 Author: michaelm Date: 2013-11-22 00:08 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/e935cd4139c6 8028293: Check local configuration for actual ephemeral port range Reviewed-by: alanb, chegar, smarks ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/net/mapfile-vers ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + src/solaris/classes/sun/net/PortConfig.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h + src/solaris/native/sun/net/portconfig.c + src/windows/classes/sun/net/PortConfig.java + src/windows/native/sun/net/portconfig.c ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 4a6e31d94b29 Author: michaelm Date: 2013-11-22 01:15 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/4a6e31d94b29 8028823: java/net/Makefile tabs converted to spaces Reviewed-by: mduigou ! make/java/net/Makefile Changeset: 41c4df1de66a Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/41c4df1de66a Added tag jdk7u51-b10 for changeset 4a6e31d94b29 ! .hgtags Changeset: f0425ecbbb0c Author: aefimov Date: 2013-11-15 13:31 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/f0425ecbbb0c 8027370: Support tzdata2013h Reviewed-by: sherman, coffeys ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f5eee4f1d5b4 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/f5eee4f1d5b4 Added tag jdk7u51-b11 for changeset f0425ecbbb0c ! .hgtags Changeset: d19a89fdfb9b Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/d19a89fdfb9b Added tag jdk7u51-b12 for changeset f5eee4f1d5b4 ! .hgtags Changeset: 402d54c7d8ce Author: mcherkas Date: 2013-10-03 17:32 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/402d54c7d8ce 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: alexp, malenkov ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 34e8f9f26ae6 Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/34e8f9f26ae6 Added tag jdk7u45-b33 for changeset 402d54c7d8ce ! .hgtags Changeset: 0cf7bf25b314 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/0cf7bf25b314 Added tag jdk7u45-b34 for changeset 34e8f9f26ae6 ! .hgtags Changeset: 107c98c89f70 Author: asaha Date: 2013-12-17 11:14 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/107c98c89f70 Merge ! .hgtags Changeset: ef58b2b9a9a1 Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/ef58b2b9a9a1 Added tag jdk7u51-b13 for changeset d19a89fdfb9b ! .hgtags Changeset: 5bca0d0969b1 Author: asaha Date: 2013-12-19 09:34 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5bca0d0969b1 Merge ! .hgtags Changeset: e627f4e75ce7 Author: goetz Date: 2014-01-23 17:00 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/e627f4e75ce7 merge ! .hgtags ! make/common/Release.gmk ! make/java/net/FILES_c.gmk ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/native/sun/font/layout/KernTable.cpp ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c ! test/java/rmi/registry/readTest/readTest.sh From goetz.lindenmaier at sap.com Thu Jan 23 08:04:37 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 23 Jan 2014 16:04:37 +0000 Subject: hg: ppc-aix-port/jdk7u/jaxp: 41 new changesets Message-ID: <20140123160543.ADEA0626D2@hg.openjdk.java.net> Changeset: d439603c2c1d Author: joehw Date: 2013-08-26 20:39 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/d439603c2c1d 8022935: Enhance Apache resolver classes Reviewed-by: alanb, mchung, skoivu ! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java Changeset: 821f4884bf5a Author: asaha Date: 2013-08-27 15:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/821f4884bf5a Merge Changeset: b58b3eebb5d9 Author: asaha Date: 2013-09-04 12:28 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/b58b3eebb5d9 Merge Changeset: 71670df6abf8 Author: asaha Date: 2013-09-11 15:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/71670df6abf8 Merge Changeset: a21c2865342f Author: asaha Date: 2013-09-12 08:10 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/a21c2865342f Merge ! .hgtags Changeset: b5cd020bcc60 Author: asaha Date: 2013-09-18 11:18 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/b5cd020bcc60 Merge ! .hgtags Changeset: ed11b0eb4ce8 Author: asaha Date: 2013-09-18 11:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/ed11b0eb4ce8 Merge ! .hgtags Changeset: 1c4467ab7019 Author: asaha Date: 2013-09-19 15:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/1c4467ab7019 Merge ! .hgtags Changeset: ae069ad1324d Author: asaha Date: 2013-09-24 10:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/ae069ad1324d Merge ! .hgtags Changeset: 47eb61009d86 Author: asaha Date: 2013-09-26 11:25 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/47eb61009d86 Merge ! .hgtags Changeset: 0af40df02030 Author: asaha Date: 2013-09-27 12:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/0af40df02030 Merge ! .hgtags Changeset: 3a348ded5559 Author: asaha Date: 2013-09-27 13:17 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/3a348ded5559 Merge ! .hgtags Changeset: 07fa2d34974d Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/07fa2d34974d Added tag jdk7u51-b00 for changeset 0a8b95184728 ! .hgtags Changeset: 2450ace952f4 Author: asaha Date: 2013-09-30 11:13 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/2450ace952f4 Merge ! .hgtags Changeset: f3bdb445348f Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/f3bdb445348f Added tag jdk7u51-b01 for changeset 2450ace952f4 ! .hgtags Changeset: 7a6fa252ff6f Author: asaha Date: 2013-10-08 11:55 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/7a6fa252ff6f Merge ! .hgtags Changeset: 68def851cc6b Author: asaha Date: 2013-10-09 09:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/68def851cc6b Merge ! .hgtags Changeset: 0df316a3b311 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/0df316a3b311 Added tag jdk7u51-b02 for changeset 68def851cc6b ! .hgtags Changeset: 1f0996368d6e Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/1f0996368d6e Added tag jdk7u51-b03 for changeset 0df316a3b311 ! .hgtags Changeset: 42be8e6266ab Author: joehw Date: 2013-10-22 12:59 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/42be8e6266ab 8025018: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, ahgross ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: 0655a95d1609 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/0655a95d1609 Added tag jdk7u51-b04 for changeset 42be8e6266ab ! .hgtags Changeset: 13a15fc9b6bf Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/13a15fc9b6bf Added tag jdk7u51-b05 for changeset 0655a95d1609 ! .hgtags Changeset: bbbfbe6d0a9f Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/bbbfbe6d0a9f Added tag jdk7u51-b06 for changeset 13a15fc9b6bf ! .hgtags Changeset: 9736e845a3c1 Author: mfang Date: 2013-11-07 12:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/9736e845a3c1 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties Changeset: 8e4523e579bf Author: mfang Date: 2013-11-07 12:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/8e4523e579bf Merge Changeset: b38271b28253 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/b38271b28253 Added tag jdk7u51-b07 for changeset 8e4523e579bf ! .hgtags Changeset: 783ceae9b736 Author: joehw Date: 2013-11-14 09:47 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/783ceae9b736 8027201: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, hawtin ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: 7875c882a751 Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/7875c882a751 Added tag jdk7u51-b08 for changeset 783ceae9b736 ! .hgtags Changeset: 8c288622817f Author: asaha Date: 2013-11-27 08:21 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/8c288622817f Added tag jdk7u51-b09 for changeset 7875c882a751 ! .hgtags Changeset: 394a207d1250 Author: coffeys Date: 2013-11-21 19:36 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/394a207d1250 8028111: XML readers share the same entity expansion counter Reviewed-by: joehw, robm ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java Changeset: 55e8ea7085b7 Author: coffeys Date: 2013-11-26 19:33 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/55e8ea7085b7 8029038: Revise fix for XML readers share the same entity expansion counter Reviewed-by: joehw, mbankal ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java Changeset: 65798d05674d Author: asaha Date: 2013-11-27 11:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/65798d05674d Merge Changeset: 70b5691c44d2 Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/70b5691c44d2 Added tag jdk7u51-b10 for changeset 65798d05674d ! .hgtags Changeset: 807946db29f4 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/807946db29f4 Added tag jdk7u51-b11 for changeset 70b5691c44d2 ! .hgtags Changeset: 114654a331e2 Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/114654a331e2 Added tag jdk7u51-b12 for changeset 807946db29f4 ! .hgtags Changeset: b5a83862ed2a Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/b5a83862ed2a Added tag jdk7u45-b33 for changeset 056494e83d15 ! .hgtags Changeset: 7fda9b300e07 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/7fda9b300e07 Added tag jdk7u45-b34 for changeset b5a83862ed2a ! .hgtags Changeset: 57466a32e645 Author: asaha Date: 2013-12-17 11:12 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/57466a32e645 Merge ! .hgtags Changeset: 3161567adae9 Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/3161567adae9 Added tag jdk7u51-b13 for changeset 114654a331e2 ! .hgtags Changeset: e85ee81daec2 Author: asaha Date: 2013-12-19 09:33 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/e85ee81daec2 Merge ! .hgtags Changeset: f9706a8c1919 Author: goetz Date: 2014-01-23 17:00 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/f9706a8c1919 merge ! .hgtags From david.holmes at oracle.com Thu Jan 23 23:28:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jan 2014 17:28:12 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52E0BCFD.8020202@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE8C35D@DEWDFEMB12A.global.corp.sap> <52D5DC80.1040003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8C5AB@DEWDFEMB12A.global.corp.sap> <52D76D50.60700@oracle.com> <52D78697.2090408@oracle.com> <52D79982.4060100@oracle.com> <52D79E61.1060801@oracle.com> <52D7A0A9.6070208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8CF70@DEWDFEMB12A.global.corp.sap> <52DDFD9D.3050205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EBA7@DEWDFEMB12A.global.corp.sap> <52DE5FB0.5000808@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EC55@DEWDFEMB12A.global.corp.sap> <52DED1D2.1070203@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8EF85@DEWDFEMB12A.global.corp.sap> <52DFF98C.8010001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8F332@DEWDFEMB12A.global.corp.sap> <52E0B26F.1000105@oracle.com> <52E0BCFD.8020202@oracle.com> Message-ID: <52E2160C.6030300@oracle.com> On 23/01/2014 4:55 PM, Vladimir Kozlov wrote: > Okay, lets resolve it. > > David, are you talking about this change?: > > http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/diff/3205e78d8193/src/share/vm/runtime/thread.hpp Yes. > Which may penalize our binaries without need. I think Goetz suggested > already to put it under #ifdef PPC64 but I may be misremember. Would > #ifdef solution satisfy you? Based on other discussions this ties in with the use, or not, of UseMembar with non-TSO systems. But an ifdef PPC64 would be okay pending more complete resolution of these matters sometime in the future. Thanks, David > Thanks, > Vladimir > > On 1/22/14 10:10 PM, David Holmes wrote: >> On 23/01/2014 3:20 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>>> Yes, I will backport it. >>> That's good, thank you! >>> >>>> I will build bundles and give them to SQE for final testing. >>> __final__ That's even better, that's great!!! >> >> Hmmm I still have reservations concerning the _thread_state changes >> that were pushed. >> >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Mittwoch, 22. Januar 2014 18:02 >>> To: Lindenmaier, Goetz >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>> Independent Reads of Independent Writes >>> >>> Hi Goetz >>> >>> On 1/22/14 1:20 AM, Lindenmaier, Goetz wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for testing and pushing! >>>> >>>> Will you push this also to stage? I assume we can handle this >>>> as the other three hotspot changes, without a new bug-id? >>> >>> Yes, I will backport it. >>> >>> What about JDK changes Volker pushed: 8028537, 8031134, 8031997 and >>> new one from today 8031581? >>> Should I backport all of them into 8u stage? From conversion between >>> Volker and Alan some of them need backport a fix >>> from jdk9. Or I am mistaking? >>> >>>> >>>> Also, when do you think we (you unfortunately) should update >>>> the repos again? Stage-9 maybe after Volkers last change is submitted? >>> >>> After I test and push 8031581 I will do sync with latest jdk9 sources >>> (b01). >>> I will build bundles and give them to SQE for final testing. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Best regards, >>>> Goetz >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: hotspot-dev-bounces at openjdk.java.net >>>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >>>> Kozlov >>>> Sent: Dienstag, 21. Januar 2014 21:00 >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>> Independent Reads of Independent Writes >>>> >>>> Thanks. I am pushing it. >>>> >>>> Vladimir >>>> >>>> On 1/21/14 5:19 AM, Lindenmaier, Goetz wrote: >>>>> Sorry, I missed that. fixed. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Dienstag, 21. Januar 2014 12:53 >>>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>> Independent Reads of Independent Writes >>>>> >>>>> Thanks Goetz! >>>>> >>>>> This typo still exists: >>>>> >>>>> + bool _wrote_volatile; // Did we write a final field? >>>>> >>>>> s/final/volatile/ >>>>> >>>>> Otherwise no further comments from me. >>>>> >>>>> David >>>>> >>>>> On 21/01/2014 7:22 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I made a new webrev >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-3-raw/ >>>>>> differing from >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>>> only in the comments. >>>>>> >>>>>> I removed >>>>>> // Support ordering of "Independent Reads of Independent Writes". >>>>>> everywhere, and edited the comments in the globalDefinition*.hpp >>>>>> files. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Dienstag, 21. Januar 2014 05:55 >>>>>> To: Lindenmaier, Goetz; Vladimir Kozlov >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>> Independent Reads of Independent Writes >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 17/01/2014 6:39 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I tried to come up with a webrev that implements the change as >>>>>>> proposed in >>>>>>> your mails: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-2-raw/ >>>>>>> >>>>>>> Wherever I used CPU_NOT_MULTIPLE_COPY_ATOMIC, I use >>>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu. >>>>>> >>>>>> Given the flag name the commentary eg: >>>>>> >>>>>> + // Support ordering of "Independent Reads of Independent >>>>>> Writes". >>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { >>>>>> >>>>>> seems somewhat redundant. >>>>>> >>>>>>> I left the definition and handling of _wrote_volatile in the >>>>>>> code, without >>>>>>> any protection. >>>>>> >>>>>> + bool _wrote_volatile; // Did we write a final field? >>>>>> >>>>>> s/final/volatile >>>>>> >>>>>>> I protected issuing the barrier for volatile in constructors with >>>>>>> PPC64_ONLY() , >>>>>>> and put it on one line. >>>>>>> >>>>>>> I removed the comment in library_call.cpp. >>>>>>> I also removed the sentence " Solution: implement volatile read >>>>>>> as sync-load-acquire." >>>>>>> from the comments as it's PPC specific. >>>>>> >>>>>> I think the primary IRIW comment/explanation should go in >>>>>> globalDefinitions.hpp where >>>>>> support_IRIW_for_not_multiple_copy_atomic_cpu is defined. >>>>>> >>>>>>> Wrt. to C1: we plan to port C1 to PPC64, too. During that task, >>>>>>> we will fix these >>>>>>> issues in C1 if nobody did it by then. >>>>>> >>>>>> I've filed: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8032366 >>>>>> >>>>>> "Implement C1 support for IRIW conformance on >>>>>> non-multiple-copy-atomic >>>>>> platforms" >>>>>> >>>>>> to cover this task, as it may be needed sooner rather than later. >>>>>> >>>>>>> Wrt. to performance: Oracle will soon do heavy testing of the >>>>>>> port. If any >>>>>>> performance problems arise, we still can add #ifdef PPC64 to >>>>>>> circumvent this. >>>>>> >>>>>> Ok. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Donnerstag, 16. Januar 2014 10:05 >>>>>>> To: Vladimir Kozlov >>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>> Independent Reads of Independent Writes >>>>>>> >>>>>>> On 16/01/2014 6:54 PM, Vladimir Kozlov wrote: >>>>>>>> On 1/16/14 12:34 AM, David Holmes wrote: >>>>>>>>> On 16/01/2014 5:13 PM, Vladimir Kozlov wrote: >>>>>>>>>> This is becoming ugly #ifdef mess. In compiler code we are >>>>>>>>>> trying to >>>>>>>>>> avoid them. I suggested to have _wrote_volatile without #ifdef >>>>>>>>>> and I >>>>>>>>>> want to keep it this way, it could be useful to have such info >>>>>>>>>> on other >>>>>>>>>> platforms too. But I would suggest to remove PPC64 comments in >>>>>>>>>> parse.hpp. >>>>>>>>>> >>>>>>>>>> In globalDefinitions.hpp after globalDefinitions_ppc.hpp >>>>>>>>>> define a value >>>>>>>>>> which could be checked in all places instead of #ifdef: >>>>>>>>> >>>>>>>>> I asked for the ifdef some time back as I find it much >>>>>>>>> preferable to >>>>>>>>> have this as a build-time construct rather than a >>>>>>>>> runtime one. I don't want to have to pay anything for this if >>>>>>>>> we don't >>>>>>>>> use it. >>>>>>>> >>>>>>>> Any decent C++ compiler will optimize expressions with such >>>>>>>> constants >>>>>>>> defined in header files. I insist to avoid #ifdefs in C2 code. I >>>>>>>> really >>>>>>>> don't like the code with #ifdef in unsafe.cpp but I can live >>>>>>>> with it. >>>>>>> >>>>>>> If you insist then we may as well do it all the same way. Better >>>>>>> to be >>>>>>> consistent. >>>>>>> >>>>>>> My apologies Goetz for wasting your time going back and forth on >>>>>>> this. >>>>>>> >>>>>>> That aside I have a further concern with this IRIW support - it is >>>>>>> incomplete as there is no C1 support, as PPC64 isn't using >>>>>>> client. If >>>>>>> this is going on then we (which probably means the Oracle 'we') >>>>>>> need to >>>>>>> add the missing C1 code. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true; >>>>>>>>>> #else >>>>>>>>>> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = false; >>>>>>>>>> #endif >>>>>>>>>> >>>>>>>>>> or support_IRIW_for_not_multiple_copy_atomic_cpu, whatever >>>>>>>>>> >>>>>>>>>> and then: >>>>>>>>>> >>>>>>>>>> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \ >>>>>>>>>> oop p = JNIHandles::resolve(obj); \ >>>>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu) >>>>>>>>>> OrderAccess::fence(); \ >>>>>>>>>> volatile type_name v = >>>>>>>>>> OrderAccess::load_acquire((volatile >>>>>>>>>> type_name*)index_oop_from_field_offset_long(p, offset)); >>>>>>>>>> >>>>>>>>>> And: >>>>>>>>>> >>>>>>>>>> + if (support_IRIW_for_not_multiple_copy_atomic_cpu && >>>>>>>>>> field->is_volatile()) { >>>>>>>>>> + insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>>> And so on. The comments will be needed only in >>>>>>>>>> globalDefinitions.hpp >>>>>>>>>> >>>>>>>>>> The code in parse1.cpp could be put on one line: >>>>>>>>>> >>>>>>>>>> + if (wrote_final() PPC64_ONLY( || (wrote_volatile() && >>>>>>>>>> method()->is_initializer()) )) { >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 1/15/14 9:25 PM, David Holmes wrote: >>>>>>>>>>> On 16/01/2014 1:28 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> I updated the webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>> >>>>>>>>>>>> - I removed the IRIW example in parse3.cpp >>>>>>>>>>>> - I adapted the comments not to point to that comment, and to >>>>>>>>>>>> reflect the new flagging. Also I mention that we >>>>>>>>>>>> support the >>>>>>>>>>>> volatile constructor issue, but that it's not standard. >>>>>>>>>>>> - I protected issuing the barrier for the constructor by PPC64. >>>>>>>>>>>> I also think it's better to separate these this way. >>>>>>>>>>> >>>>>>>>>>> Sorry if I wasn't clear but I'd like the wrote_volatile field >>>>>>>>>>> declaration and all uses to be guarded by ifdef PPC64 too >>>>>>>>>>> please. >>>>>>>>>>> >>>>>>>>>>> One nit I missed before. In >>>>>>>>>>> src/share/vm/opto/library_call.cpp this >>>>>>>>>>> comment doesn't make much sense to me and refers to >>>>>>>>>>> ppc specific stuff in a shared file: >>>>>>>>>>> >>>>>>>>>>> if (is_volatile) { >>>>>>>>>>> ! if (!is_store) { >>>>>>>>>>> insert_mem_bar(Op_MemBarAcquire); >>>>>>>>>>> ! } else { >>>>>>>>>>> ! #ifndef CPU_NOT_MULTIPLE_COPY_ATOMIC >>>>>>>>>>> ! // Changed volatiles/Unsafe: lwsync-store, >>>>>>>>>>> sync-load-acquire. >>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); >>>>>>>>>>> + #endif >>>>>>>>>>> + } >>>>>>>>>>> >>>>>>>>>>> I don't think the comment is needed. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Thanks for your comments! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Mittwoch, 15. Januar 2014 01:55 >>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the delay in getting back to this. >>>>>>>>>>>> >>>>>>>>>>>> The general changes to the volatile barriers to support IRIW >>>>>>>>>>>> are okay. >>>>>>>>>>>> The guard of CPU_NOT_MULTIPLE_COPY_ATOMIC works for this >>>>>>>>>>>> (though more >>>>>>>>>>>> specifically it is >>>>>>>>>>>> not-multiple-copy-atomic-and-chooses-to-support-IRIW). I >>>>>>>>>>>> find much of >>>>>>>>>>>> the commentary excessive, particularly for shared code. In >>>>>>>>>>>> particular >>>>>>>>>>>> the IRIW example in parse3.cpp - it seems a strange place to >>>>>>>>>>>> give the >>>>>>>>>>>> explanation and I don't think we need it to that level of >>>>>>>>>>>> detail. >>>>>>>>>>>> Seems >>>>>>>>>>>> to me that is present is globalDefinitions_ppc.hpp is quite >>>>>>>>>>>> adequate. >>>>>>>>>>>> >>>>>>>>>>>> The changes related to volatile writes in the constructor, as >>>>>>>>>>>> discussed >>>>>>>>>>>> are not required by the Java Memory Model. If you want to >>>>>>>>>>>> keep these >>>>>>>>>>>> then I think they should all be guarded with PPC64 because >>>>>>>>>>>> it is not >>>>>>>>>>>> related to CPU_NOT_MULTIPLE_COPY_ATOMIC but a choice being >>>>>>>>>>>> made by the >>>>>>>>>>>> PPC64 porters. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 14/01/2014 11:52 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I updated this webrev. I detected a small flaw I made when >>>>>>>>>>>>> editing >>>>>>>>>>>>> this version. >>>>>>>>>>>>> The #endif in line 322, parse3.cpp was in the wrong line. >>>>>>>>>>>>> I also based the webrev on the latest version of the stage >>>>>>>>>>>>> repo. >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lindenmaier, Goetz >>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 13:47 >>>>>>>>>>>>> To: David Holmes >>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: RE: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>>> So we can at least undo #4 now we have established those >>>>>>>>>>>>>> tests were >>>>>>>>>>>>>> not >>>>>>>>>>>>>> required to pass. >>>>>>>>>>>>> We would prefer if we could keep this in. We want to avoid >>>>>>>>>>>>> that it's >>>>>>>>>>>>> blamed on the VM if java programs are failing on PPC after >>>>>>>>>>>>> they >>>>>>>>>>>>> worked >>>>>>>>>>>>> on x86. To clearly mark it as overfulfilling the spec I >>>>>>>>>>>>> would guard >>>>>>>>>>>>> it by >>>>>>>>>>>>> a flag as proposed. But if you insist I will remove it. >>>>>>>>>>>>> Also, this >>>>>>>>>>>>> part is >>>>>>>>>>>>> not that performance relevant. >>>>>>>>>>>>> >>>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a >>>>>>>>>>>>>> runtime one I >>>>>>>>>>>>>> think >>>>>>>>>>>>> I added a compile-time guard in this new webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-1-raw/ >>>>>>>>>>>>> I've chosen CPU_NOT_MULTIPLE_COPY_ATOMIC. This introduces >>>>>>>>>>>>> several double negations I don't like, (#ifNdef >>>>>>>>>>>>> CPU_NOT_MULTIPLE_COPY_ATOMIC) >>>>>>>>>>>>> but this way I only have to change the ppc platform. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz >>>>>>>>>>>>> >>>>>>>>>>>>> P.S.: I will also be available over the Christmas period. >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Freitag, 20. Dezember 2013 05:58 >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the delay, it takes a while to catch up after two >>>>>>>>>>>>> weeks >>>>>>>>>>>>> vacation :) Next vacation (ie next two weeks) I'll continue >>>>>>>>>>>>> to check >>>>>>>>>>>>> emails. >>>>>>>>>>>>> >>>>>>>>>>>>> On 2/12/2013 6:33 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> ok, I understand the tests are wrong. It's good this >>>>>>>>>>>>>> issue is >>>>>>>>>>>>>> settled. >>>>>>>>>>>>>> Thanks Aleksey and Andreas for going into the details of >>>>>>>>>>>>>> the proof! >>>>>>>>>>>>>> >>>>>>>>>>>>>> About our change: David, the causality is the other way >>>>>>>>>>>>>> round. >>>>>>>>>>>>>> The change is about IRIW. >>>>>>>>>>>>>> 1. To pass IRIW, we must use sync instructions before loads. >>>>>>>>>>>>> >>>>>>>>>>>>> This is the part I still have some question marks over as the >>>>>>>>>>>>> implications are not nice for performance on non-TSO >>>>>>>>>>>>> platforms. >>>>>>>>>>>>> But I'm >>>>>>>>>>>>> no further along in processing that paper I'm afraid. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. If we do syncs before loads, we don't need to do them >>>>>>>>>>>>>> after >>>>>>>>>>>>>> stores. >>>>>>>>>>>>>> 3. If we don't do them after stores, we fail the volatile >>>>>>>>>>>>>> constructor tests. >>>>>>>>>>>>>> 4. So finally we added them again at the end of the >>>>>>>>>>>>>> constructor >>>>>>>>>>>>>> after stores >>>>>>>>>>>>>> to pass the volatile constructor tests. >>>>>>>>>>>>> >>>>>>>>>>>>> So we can at least undo #4 now we have established those tests >>>>>>>>>>>>> were not >>>>>>>>>>>>> required to pass. >>>>>>>>>>>>> >>>>>>>>>>>>>> We originally passed the constructor tests because the ppc >>>>>>>>>>>>>> memory >>>>>>>>>>>>>> order >>>>>>>>>>>>>> instructions are not as find-granular as the >>>>>>>>>>>>>> operations in the IR. MemBarVolatile is specified as >>>>>>>>>>>>>> StoreLoad. >>>>>>>>>>>>>> The only instruction >>>>>>>>>>>>>> on PPC that does StoreLoad is sync. But sync also does >>>>>>>>>>>>>> StoreStore, >>>>>>>>>>>>>> therefore the >>>>>>>>>>>>>> MemBarVolatile after the store fixes the constructor >>>>>>>>>>>>>> tests. The >>>>>>>>>>>>>> proper representation >>>>>>>>>>>>>> of the fix in the IR would be adding a MemBarStoreStore. >>>>>>>>>>>>>> But now >>>>>>>>>>>>>> it's pointless >>>>>>>>>>>>>> anyways. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block it. >>>>>>>>>>>>>> I'd be happy to add a property >>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>>> >>>>>>>>>>>>> A compile-time guard (ifdef) would be better than a runtime >>>>>>>>>>>>> one I >>>>>>>>>>>>> think >>>>>>>>>>>>> - similar to the SUPPORTS_NATIVE_CX8 optimization >>>>>>>>>>>>> (something semantic >>>>>>>>>>>>> based not architecture based) as that will allows for >>>>>>>>>>>>> turning this >>>>>>>>>>>>> on/off for any architecture for testing purposes. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> or the like to guard the customization. I'd like that >>>>>>>>>>>>>> much better. >>>>>>>>>>>>>> Or also >>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Donnerstag, 28. November 2013 00:34 >>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>> >>>>>>>>>>>>>> TL;DR version: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Discussion on the c-i list has now confirmed that a >>>>>>>>>>>>>> constructor-barrier >>>>>>>>>>>>>> for volatiles is not required as part of the JMM >>>>>>>>>>>>>> specification. It >>>>>>>>>>>>>> *may* >>>>>>>>>>>>>> be required in an implementation that doesn't pre-zero >>>>>>>>>>>>>> memory to >>>>>>>>>>>>>> ensure >>>>>>>>>>>>>> you can't see uninitialized fields. So the tests for this are >>>>>>>>>>>>>> invalid >>>>>>>>>>>>>> and this part of the patch is not needed in general (ppc64 >>>>>>>>>>>>>> may >>>>>>>>>>>>>> need it >>>>>>>>>>>>>> due to other factors). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Re: "multiple copy atomicity" - first thanks for >>>>>>>>>>>>>> correcting the >>>>>>>>>>>>>> term :) >>>>>>>>>>>>>> Second thanks for the reference to that paper! For reference: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "The memory system (perhaps involving a hierarchy of >>>>>>>>>>>>>> buffers and a >>>>>>>>>>>>>> complex interconnect) does not guarantee that a write becomes >>>>>>>>>>>>>> visible to >>>>>>>>>>>>>> all other hardware threads at the same time point; these >>>>>>>>>>>>>> architectures >>>>>>>>>>>>>> are not multiple-copy atomic." >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is the visibility issue that I referred to and >>>>>>>>>>>>>> affects both >>>>>>>>>>>>>> ARM and >>>>>>>>>>>>>> PPC. But of course it is normally handled by using >>>>>>>>>>>>>> suitable barriers >>>>>>>>>>>>>> after the stores that need to be visible. I think the crux >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> current issue is what you wrote below: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > The fixes for the constructor issue are only >>>>>>>>>>>>>> needed because we >>>>>>>>>>>>>> > remove the sync instruction from behind stores >>>>>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>>>>> > and place it before loads. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I hadn't grasped this part. Obviously if you fail to do >>>>>>>>>>>>>> the sync >>>>>>>>>>>>>> after >>>>>>>>>>>>>> the store then you have to do something around the loads >>>>>>>>>>>>>> to get the >>>>>>>>>>>>>> same >>>>>>>>>>>>>> results! I still don't know what lead you to the >>>>>>>>>>>>>> conclusion that the >>>>>>>>>>>>>> only way to fix the IRIW issue was to put the fence before >>>>>>>>>>>>>> the >>>>>>>>>>>>>> load - >>>>>>>>>>>>>> maybe when I get the chance to read that paper in full it >>>>>>>>>>>>>> will be >>>>>>>>>>>>>> clearer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So ... the basic problem is that the current structure in >>>>>>>>>>>>>> the VM has >>>>>>>>>>>>>> hard-wired one choice of how to get the right semantics >>>>>>>>>>>>>> for volatile >>>>>>>>>>>>>> variables. You now want to customize that but not all the >>>>>>>>>>>>>> requisite >>>>>>>>>>>>>> hooks are present. It would be better if volatile_load and >>>>>>>>>>>>>> volatile_store were factored out so that they could be >>>>>>>>>>>>>> implemented as >>>>>>>>>>>>>> desired per-platform. Alternatively there could be pre- >>>>>>>>>>>>>> and post- >>>>>>>>>>>>>> hooks >>>>>>>>>>>>>> that could then be customized per platform. Otherwise you >>>>>>>>>>>>>> need >>>>>>>>>>>>>> platform-specific ifdef's to handle it as per your patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not happy with the ifdef approach but I won't block >>>>>>>>>>>>>> it. I think >>>>>>>>>>>>>> this >>>>>>>>>>>>>> is an area where a lot of clean up is needed in the VM. >>>>>>>>>>>>>> The barrier >>>>>>>>>>>>>> abstractions are a confused mess in my opinion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I updated the webrev to fix the issues mentioned by >>>>>>>>>>>>>>> Vladimir: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I did not yet add the >>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>>> or >>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_copy_atomic() >>>>>>>>>>>>>>> to reduce #defined, as I got no further comment on that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WRT to the validity of the tests and the interpretation >>>>>>>>>>>>>>> of the JMM >>>>>>>>>>>>>>> I feel not in the position to contribute substantially. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But we would like to pass the torture test suite as we >>>>>>>>>>>>>>> consider >>>>>>>>>>>>>>> this a substantial task in implementing a PPC port. Also >>>>>>>>>>>>>>> we think >>>>>>>>>>>>>>> both tests show behavior a programmer would expect. It's >>>>>>>>>>>>>>> bad if >>>>>>>>>>>>>>> Java code runs fine on the more common x86 platform, and >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> fails on ppc. This will always first be blamed on the VM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The fixes for the constructor issue are only needed >>>>>>>>>>>>>>> because we >>>>>>>>>>>>>>> remove the sync instruction from behind stores >>>>>>>>>>>>>>> (parse3.cpp:320) >>>>>>>>>>>>>>> and place it before loads. Then there is no sync between >>>>>>>>>>>>>>> volatile >>>>>>>>>>>>>>> store >>>>>>>>>>>>>>> and publishing the object. So we add it again in this >>>>>>>>>>>>>>> one case >>>>>>>>>>>>>>> (volatile store in constructor). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @David >>>>>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>>>>> taskqueue problem yet, >>>>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly >>>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>> continuous. >>>>>>>>>>>>>>> That's not true, we did a lot of investigation and >>>>>>>>>>>>>>> testing on this >>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>> And we came up with a solution we consider the best >>>>>>>>>>>>>>> possible. If >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> have objections, you should at least give the draft of a >>>>>>>>>>>>>>> better >>>>>>>>>>>>>>> solution, >>>>>>>>>>>>>>> we would volunteer to implement and test it. >>>>>>>>>>>>>>> Similarly, we invested time in fixing the concurrency >>>>>>>>>>>>>>> torture >>>>>>>>>>>>>>> issues. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @David >>>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with >>>>>>>>>>>>>>>> the term >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>>>> We learned about this reading "A Tutorial Introduction to >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> ARM and >>>>>>>>>>>>>>> POWER Relaxed Memory Models" by Luc Maranget, Susmit >>>>>>>>>>>>>>> Sarkar and >>>>>>>>>>>>>>> Peter Sewell, which is cited in "Correct and Efficient >>>>>>>>>>>>>>> Work-Stealing for >>>>>>>>>>>>>>> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert >>>>>>>>>>>>>>> Cohen >>>>>>>>>>>>>>> and Francesco Zappa Nardelli (PPoPP `13) when analysing the >>>>>>>>>>>>>>> taskqueue problem. >>>>>>>>>>>>>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was wrong in one thing, it's called multiple copy >>>>>>>>>>>>>>> atomicity, I >>>>>>>>>>>>>>> used 'read' >>>>>>>>>>>>>>> instead. Sorry for that. (I also fixed that in the >>>>>>>>>>>>>>> method name >>>>>>>>>>>>>>> above). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards and thanks for all your involvements, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Mittwoch, 27. November 2013 12:53 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Volatile in constuctor >>>>>>>>>>>>>>>>> AFAIK we have not seen those tests fail due to a >>>>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>>>> We see them on PPC64. Our test machines have typically 8-32 >>>>>>>>>>>>>>>> processors >>>>>>>>>>>>>>>> and are Power 5-7. But see also Aleksey's mail. (Thanks >>>>>>>>>>>>>>>> Aleksey!) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And see follow ups - the tests are invalid. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- IRIW issue >>>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of >>>>>>>>>>>>>>>>> detail with >>>>>>>>>>>>>>>>> a few >>>>>>>>>>>>>>>>> moments thought. >>>>>>>>>>>>>>>> Sure. There also is no solution as you require for the >>>>>>>>>>>>>>>> taskqueue >>>>>>>>>>>>>>>> problem yet, >>>>>>>>>>>>>>>> and that's being discussed now for almost a year. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It may have started a year ago but work on it has hardly >>>>>>>>>>>>>>> been >>>>>>>>>>>>>>> continuous. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You are implying there is a problem here that will >>>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why >>>>>>>>>>>>>>>>> ppc is so >>>>>>>>>>>>>>>>> different?) >>>>>>>>>>>>>>>> No, only PPC does not have 'multiple-read-atomicity'. >>>>>>>>>>>>>>>> Therefore >>>>>>>>>>>>>>>> I contributed a >>>>>>>>>>>>>>>> solution with the #defines, and that's correct for all, >>>>>>>>>>>>>>>> but not >>>>>>>>>>>>>>>> nice, I admit. >>>>>>>>>>>>>>>> (I don't really know about ARM, though). >>>>>>>>>>>>>>>> So if I can write down a nicer solution testing for >>>>>>>>>>>>>>>> methods that >>>>>>>>>>>>>>>> are evaluated >>>>>>>>>>>>>>>> by the C-compiler I'm happy. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The problem is not that IRIW is not handled by the JMM, the >>>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>>> is that >>>>>>>>>>>>>>>> store >>>>>>>>>>>>>>>> sync >>>>>>>>>>>>>>>> does not assure multiple-read-atomicity, >>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>> sync >>>>>>>>>>>>>>>> load >>>>>>>>>>>>>>>> does so on PPC. And you require multiple-read-atomicity to >>>>>>>>>>>>>>>> pass that test. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What is "multiple-read-atomicity"? I'm not familiar with the >>>>>>>>>>>>>>> term and >>>>>>>>>>>>>>> can't find any reference to it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The JMM is fine. And >>>>>>>>>>>>>>>> store >>>>>>>>>>>>>>>> MemBarVolatile >>>>>>>>>>>>>>>> is fine on x86, sparc etc. as there exist assembler >>>>>>>>>>>>>>>> instructions >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> do what is required. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So if you are off soon, please let's come to a solution >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> might be improvable in the way it's implemented, but that >>>>>>>>>>>>>>>> allows us to implement a correct PPC64 port. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 1:11 PM >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; >>>>>>>>>>>>>>>> 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of >>>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> thanks a lot for the detailed reviews! >>>>>>>>>>>>>>>>> I'll try to answer to all in one mail. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Volatile fields written in constructor aren't >>>>>>>>>>>>>>>>>> guaranteed by JMM >>>>>>>>>>>>>>>>>> to occur before the reference is assigned; >>>>>>>>>>>>>>>>> We don't think it's correct if we omit the barrier after >>>>>>>>>>>>>>>>> initializing >>>>>>>>>>>>>>>>> a volatile field. Previously, we discussed this with >>>>>>>>>>>>>>>>> Aleksey >>>>>>>>>>>>>>>>> Shipilev >>>>>>>>>>>>>>>>> and Doug Lea, and they agreed. >>>>>>>>>>>>>>>>> Also, concurrency torture tests >>>>>>>>>>>>>>>>> LongVolatileTest >>>>>>>>>>>>>>>>> AtomicIntegerInitialValueTest >>>>>>>>>>>>>>>>> will fail. >>>>>>>>>>>>>>>>> (In addition, observing 0 instead of the inital value of a >>>>>>>>>>>>>>>>> volatile field would be >>>>>>>>>>>>>>>>> very counter-intuitive for Java programmers, especially in >>>>>>>>>>>>>>>>> AtomicInteger.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The affects of unsafe publication are always surprising - >>>>>>>>>>>>>>>> volatiles do >>>>>>>>>>>>>>>> not add anything special here. AFAIK there is nothing in >>>>>>>>>>>>>>>> the JMM >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> requires the constructor barrier - discussions with Doug >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> Aleksey >>>>>>>>>>>>>>>> notwithstanding. AFAIK we have not seen those tests fail >>>>>>>>>>>>>>>> due to a >>>>>>>>>>>>>>>> missing constructor barrier. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> proposed for PPC64 is to make volatile reads extremely >>>>>>>>>>>>>>>>>> heavyweight >>>>>>>>>>>>>>>>> Yes, it costs measurable performance. But else it is >>>>>>>>>>>>>>>>> wrong. We >>>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>> see a way to implement this cheaper. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - these algorithms should be expressed using the correct >>>>>>>>>>>>>>>>>> OrderAccess operations >>>>>>>>>>>>>>>>> Basically, I agree on this. But you also have to take >>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>> account >>>>>>>>>>>>>>>>> that due to the different memory ordering instructions on >>>>>>>>>>>>>>>>> different platforms >>>>>>>>>>>>>>>>> just implementing something empty is not sufficient. >>>>>>>>>>>>>>>>> An example: >>>>>>>>>>>>>>>>> MemBarRelease // means LoadStore, >>>>>>>>>>>>>>>>> StoreStore barrier >>>>>>>>>>>>>>>>> MemBarVolatile // means StoreLoad barrier >>>>>>>>>>>>>>>>> If these are consecutively in the code, sparc code >>>>>>>>>>>>>>>>> looks like >>>>>>>>>>>>>>>>> this: >>>>>>>>>>>>>>>>> MemBarRelease --> >>>>>>>>>>>>>>>>> membar(Assembler::LoadStore | >>>>>>>>>>>>>>>>> Assembler::StoreStore) >>>>>>>>>>>>>>>>> MemBarVolatile --> >>>>>>>>>>>>>>>>> membar(Assembler::StoreLoad) >>>>>>>>>>>>>>>>> Just doing what is required. >>>>>>>>>>>>>>>>> On Power, we get suboptimal code, as there are no >>>>>>>>>>>>>>>>> comparable, >>>>>>>>>>>>>>>>> fine grained operations: >>>>>>>>>>>>>>>>> MemBarRelease --> lwsync // Doing >>>>>>>>>>>>>>>>> LoadStore, >>>>>>>>>>>>>>>>> StoreStore, LoadLoad >>>>>>>>>>>>>>>>> MemBarVolatile --> sync // // Doing >>>>>>>>>>>>>>>>> LoadStore, >>>>>>>>>>>>>>>>> StoreStore, LoadLoad, StoreLoad >>>>>>>>>>>>>>>>> obviously, the lwsync is superfluous. Thus, as PPC >>>>>>>>>>>>>>>>> operations >>>>>>>>>>>>>>>>> are more (too) powerful, >>>>>>>>>>>>>>>>> I need an additional optimization that removes the >>>>>>>>>>>>>>>>> lwsync. I >>>>>>>>>>>>>>>>> can not implement >>>>>>>>>>>>>>>>> MemBarRelease empty, as it is also used independently. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Back to the IRIW problem. I think here we have a >>>>>>>>>>>>>>>>> comparable >>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>> Doing the MemBarVolatile or the OrderAccess::fence() >>>>>>>>>>>>>>>>> before the >>>>>>>>>>>>>>>>> read >>>>>>>>>>>>>>>>> is inefficient on platforms that have >>>>>>>>>>>>>>>>> multiple-read-atomicity. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would propose to guard the code by >>>>>>>>>>>>>>>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>>>>>>>>>>>>>>> OrderAccess::cpu_is_multiple_read_atomic() >>>>>>>>>>>>>>>>> Else, David, how would you propose to implement this >>>>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>>>> (Maybe we can also use above method in taskqueue.hpp.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can not possibly answer to the necessary level of >>>>>>>>>>>>>>>> detail with a >>>>>>>>>>>>>>>> few >>>>>>>>>>>>>>>> moments thought. You are implying there is a problem >>>>>>>>>>>>>>>> here that >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> impact numerous platforms (unless you can tell me why >>>>>>>>>>>>>>>> ppc is so >>>>>>>>>>>>>>>> different?) and I can not take that on face value at the >>>>>>>>>>>>>>>> moment. The >>>>>>>>>>>>>>>> only reason I can see IRIW not being handled by the JMM >>>>>>>>>>>>>>>> requirements for >>>>>>>>>>>>>>>> volatile accesses is if there are global visibility >>>>>>>>>>>>>>>> issues that >>>>>>>>>>>>>>>> are not >>>>>>>>>>>>>>>> addressed - but even then I would expect heavy barriers >>>>>>>>>>>>>>>> at the >>>>>>>>>>>>>>>> store >>>>>>>>>>>>>>>> would deal with that, not at the load. (This situation >>>>>>>>>>>>>>>> reminds me >>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>> need for read-barriers on Alpha architecture due to the >>>>>>>>>>>>>>>> use of >>>>>>>>>>>>>>>> software >>>>>>>>>>>>>>>> cache-coherency rather than hardware cache-coherency - >>>>>>>>>>>>>>>> but we >>>>>>>>>>>>>>>> don't have >>>>>>>>>>>>>>>> that on ppc!) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry - There is no quick resolution here and in a >>>>>>>>>>>>>>>> couple of days >>>>>>>>>>>>>>>> I will >>>>>>>>>>>>>>>> be heading out on vacation for two weeks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- Other ports: >>>>>>>>>>>>>>>>> The IRIW issue requires at least 3 processors to be >>>>>>>>>>>>>>>>> relevant, so >>>>>>>>>>>>>>>>> it might >>>>>>>>>>>>>>>>> not happen on small machines. But I can use PPC_ONLY >>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>> of PPC64_ONLY if you request so (and if we don't get >>>>>>>>>>>>>>>>> rid of >>>>>>>>>>>>>>>>> them). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- MemBarStoreStore after initialization >>>>>>>>>>>>>>>>> I agree we should not change it in the ppc port. If >>>>>>>>>>>>>>>>> you wish, I >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> prepare an extra webrev for hotspot-comp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>>>>>>>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): >>>>>>>>>>>>>>>>> ordering of >>>>>>>>>>>>>>>>> Independent Reads of Independent Writes >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Okay this is my second attempt at answering this in a >>>>>>>>>>>>>>>>> reasonable >>>>>>>>>>>>>>>>> way :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>>>>> I have to ask David to do correctness evaluation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From what I understand what we see here is >>>>>>>>>>>>>>>>> an attempt to >>>>>>>>>>>>>>>>> fix an >>>>>>>>>>>>>>>>> existing issue with the implementation of volatiles so >>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>> IRIW >>>>>>>>>>>>>>>>> problem is addressed. The solution proposed for PPC64 >>>>>>>>>>>>>>>>> is to make >>>>>>>>>>>>>>>>> volatile reads extremely heavyweight by adding a >>>>>>>>>>>>>>>>> fence() when >>>>>>>>>>>>>>>>> doing the >>>>>>>>>>>>>>>>> load. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Now if this was purely handled in ppc64 source code then I >>>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>>> happy to let them do whatever they like (surely this kills >>>>>>>>>>>>>>>>> performance >>>>>>>>>>>>>>>>> though!). But I do not agree with the changes to the >>>>>>>>>>>>>>>>> shared code >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> allow this solution to be implemented - even with >>>>>>>>>>>>>>>>> PPC64_ONLY >>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>> polluting the shared code. My concern is similar to >>>>>>>>>>>>>>>>> what I said >>>>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>>>> taskQueue changes - these algorithms should be >>>>>>>>>>>>>>>>> expressed using >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> correct OrderAccess operations to guarantee the desired >>>>>>>>>>>>>>>>> properties >>>>>>>>>>>>>>>>> independent of architecture. If such a "barrier" is not >>>>>>>>>>>>>>>>> needed >>>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>>> given architecture then the implementation in >>>>>>>>>>>>>>>>> OrderAccess should >>>>>>>>>>>>>>>>> reduce >>>>>>>>>>>>>>>>> to a no-op. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And as Vitaly points out the constructor barriers are >>>>>>>>>>>>>>>>> not needed >>>>>>>>>>>>>>>>> under >>>>>>>>>>>>>>>>> the JMM. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am fine with suggested changes because you did not >>>>>>>>>>>>>>>>>> change our >>>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>>> code for our platforms (please, do not change >>>>>>>>>>>>>>>>>> do_exits() now). >>>>>>>>>>>>>>>>>> But may be it should be done using more general query >>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>>>>> depending on platform: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OrderAccess::needs_support_iriw_ordering() >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> or similar to what we use now: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> VM_Version::needs_support_iriw_ordering() >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Every platform has to support IRIW this is simply part >>>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>>> Memory Model, there should not be any need to call this >>>>>>>>>>>>>>>>> out >>>>>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>>>>> like this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is there some subtlety of the hardware I am missing >>>>>>>>>>>>>>>>> here? Are >>>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>>> visibility issues beyond the ordering constraints that >>>>>>>>>>>>>>>>> the JMM >>>>>>>>>>>>>>>>> defines? >>>>>>>>>>>>>>>>>> From what I understand our ppc port is >>>>>>>>>>>>>>>>>> also affected. >>>>>>>>>>>>>>>>>> David? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We can not discuss that on an OpenJDK mailing list - >>>>>>>>>>>>>>>>> sorry. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In library_call.cpp can you add {}? New comment should be >>>>>>>>>>>>>>>>>> inside else {}. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think you should make _wrote_volatile field not ppc64 >>>>>>>>>>>>>>>>>> specific which >>>>>>>>>>>>>>>>>> will be set to 'true' only on ppc64. Then you will not >>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>> PPC64_ONLY() >>>>>>>>>>>>>>>>>> except in do_put_xxx() where it is set to true. Too many >>>>>>>>>>>>>>>>>> #ifdefs. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In do_put_xxx() can you combine your changes: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> if (is_vol) { >>>>>>>>>>>>>>>>>> // See comment in do_get_xxx(). >>>>>>>>>>>>>>>>>> #ifndef PPC64 >>>>>>>>>>>>>>>>>> insert_mem_bar(Op_MemBarVolatile); // >>>>>>>>>>>>>>>>>> Use fat membar >>>>>>>>>>>>>>>>>> #else >>>>>>>>>>>>>>>>>> if (is_field) { >>>>>>>>>>>>>>>>>> // Add MemBarRelease for >>>>>>>>>>>>>>>>>> constructors which write >>>>>>>>>>>>>>>>>> volatile field >>>>>>>>>>>>>>>>>> (PPC64). >>>>>>>>>>>>>>>>>> set_wrote_volatile(true); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I preprared a webrev with fixes for PPC for the >>>>>>>>>>>>>>>>>>> VolatileIRIWTest of >>>>>>>>>>>>>>>>>>> the torture test suite: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Example: >>>>>>>>>>>>>>>>>>> volatile x=0, y=0 >>>>>>>>>>>>>>>>>>> __________ __________ >>>>>>>>>>>>>>>>>>> __________ __________ >>>>>>>>>>>>>>>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> write(x=1) read(x) >>>>>>>>>>>>>>>>>>> write(y=1) read(y) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> read(y) read(x) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Solution: This example requires >>>>>>>>>>>>>>>>>>> multiple-copy-atomicity. This >>>>>>>>>>>>>>>>>>> is only >>>>>>>>>>>>>>>>>>> assured by the sync instruction and if it is executed >>>>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>>>> doing the loads. Thus we implement volatile read as >>>>>>>>>>>>>>>>>>> sync-load-acquire >>>>>>>>>>>>>>>>>>> and omit the sync/MemBarVolatile after the volatile >>>>>>>>>>>>>>>>>>> store. >>>>>>>>>>>>>>>>>>> MemBarVolatile happens to be implemented by sync. >>>>>>>>>>>>>>>>>>> We fix this in C2 and the cpp interpreter. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This addresses a similar issue as fix "8012144: multiple >>>>>>>>>>>>>>>>>>> SIGSEGVs >>>>>>>>>>>>>>>>>>> fails on staxf" for taskqueue.hpp. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Further this change contains a fix that assures that >>>>>>>>>>>>>>>>>>> volatile >>>>>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>>>>> written in constructors are visible before the >>>>>>>>>>>>>>>>>>> reference gets >>>>>>>>>>>>>>>>>>> published. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Looking at the code, we found a MemBarRelease that to >>>>>>>>>>>>>>>>>>> us, >>>>>>>>>>>>>>>>>>> seems too >>>>>>>>>>>>>>>>>>> strong. >>>>>>>>>>>>>>>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore >>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>> suffice. >>>>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Fri Jan 24 01:42:03 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 24 Jan 2014 09:42:03 +0000 Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> Hi, please review and test this small change: http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/ Please also review it for jdk8u. There are concerns that the OrderAccess operations we added to accesses of _thead_state for ppc64 harm performance on other platforms. Thus this change adds guards #ifdef PPC64 around it. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140124/e20ffc12/attachment.html From david.holmes at oracle.com Fri Jan 24 03:32:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jan 2014 21:32:40 +1000 Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> Message-ID: <52E24F58.1090101@oracle.com> Ok. Thanks Goetz. David On 24/01/2014 7:42 PM, Lindenmaier, Goetz wrote: > Hi, > > please review and test this small change: > > http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/ > > Please also review it for jdk8u. > > There are concerns that the OrderAccess operations we added to accesses of > > _/thead/_state for ppc64 harm performance on other platforms. Thus this > change adds > > guards #ifdef PPC64 around it. > > Best regards, > > Goetz. > From vladimir.kozlov at oracle.com Fri Jan 24 06:35:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 06:35:56 -0800 Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> Message-ID: <52E27A4C.6040806@oracle.com> Why you used #if !defined() instead of #ifndef? We usually use #ifndef when checking one parameter. Thanks, Vladimir On 1/24/14 1:42 AM, Lindenmaier, Goetz wrote: > Hi, > > please review and test this small change: > > http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/ > > Please also review it for jdk8u. > > There are concerns that the OrderAccess operations we added to accesses of > > _/thead/_state for ppc64 harm performance on other platforms. Thus this change adds > > guards #ifdef PPC64 around it. > > Best regards, > > Goetz. > From goetz.lindenmaier at sap.com Fri Jan 24 06:54:24 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 24 Jan 2014 14:54:24 +0000 Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. In-Reply-To: <52E27A4C.6040806@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E27A4C.6040806@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE8FC6E@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I updated it. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 24. Januar 2014 15:36 To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; David Holmes Subject: Re: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Why you used #if !defined() instead of #ifndef? We usually use #ifndef when checking one parameter. Thanks, Vladimir On 1/24/14 1:42 AM, Lindenmaier, Goetz wrote: > Hi, > > please review and test this small change: > > http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/ > > Please also review it for jdk8u. > > There are concerns that the OrderAccess operations we added to accesses of > > _/thead/_state for ppc64 harm performance on other platforms. Thus this change adds > > guards #ifdef PPC64 around it. > > Best regards, > > Goetz. > From vladimir.kozlov at oracle.com Fri Jan 24 06:56:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 06:56:33 -0800 Subject: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8FC6E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E27A4C.6040806@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE8FC6E@DEWDFEMB12A.global.corp.sap> Message-ID: <52E27F21.403@oracle.com> Thanks. I will push it using JPRT. Vladimir On 1/24/14 6:54 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I updated it. > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 24. Januar 2014 15:36 > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; David Holmes > Subject: Re: RFR (XS): 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. > > Why you used #if !defined() instead of #ifndef? We usually use #ifndef when checking one parameter. > > Thanks, > Vladimir > > On 1/24/14 1:42 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> please review and test this small change: >> >> http://cr.openjdk.java.net/~goetz/webrevs/8032634-1-ifdef/ >> >> Please also review it for jdk8u. >> >> There are concerns that the OrderAccess operations we added to accesses of >> >> _/thead/_state for ppc64 harm performance on other platforms. Thus this change adds >> >> guards #ifdef PPC64 around it. >> >> Best regards, >> >> Goetz. >> From vladimir.kozlov at oracle.com Fri Jan 24 09:38:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 09:38:52 -0800 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> Message-ID: <52E2A52C.3080801@oracle.com> Hi, Before the merge of ppc64 port into our main sources I have to undo this change which simplified testing (no need for separate JPRT jobs) during pushes into ppc64 staging repo. Gary Collins is working on these changes for our main sources. http://cr.openjdk.java.net/~kvn/8029941/webrev/ It will also be backported into 8u20 later. Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Jan 24 10:39:58 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 24 Jan 2014 18:39:58 +0000 Subject: hg: ppc-aix-port/stage-9/hotspot: 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Message-ID: <20140124184011.294F462772@hg.openjdk.java.net> Changeset: 6a6c94b49dab Author: goetz Date: 2014-01-24 10:23 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/6a6c94b49dab 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Reviewed-by: dholmes, kvn ! src/share/vm/runtime/thread.hpp From vladimir.kozlov at oracle.com Fri Jan 24 11:57:51 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 24 Jan 2014 19:57:51 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Message-ID: <20140124195808.6F70C62775@hg.openjdk.java.net> Changeset: 3f3c97187f82 Author: goetz Date: 2014-01-24 10:23 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/3f3c97187f82 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Reviewed-by: dholmes, kvn ! src/share/vm/runtime/thread.hpp From vladimir.kozlov at oracle.com Fri Jan 24 14:15:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 14:15:18 -0800 Subject: Merging ppc64 port into jdk9 Message-ID: <52E2E5F6.7060703@oracle.com> Hi, I am waiting approval from SQE and start thinking about merge itself. I think the best would be to merge into one of our group repos, for example jdk9/hs-comp, to get extensive Nightly and other testing before propagating into jdk9 master. The main question for me is what about jdk and top dir changes? They will not be tested until they are propagated into jdk9/dev. Is it possible to split the merge and push Hotspot changes into jdk9/hs-comp/hotspot and the rest into jdk9/dev? I will try to do JPRT control run of stage-9 without Hotspot changes. thanks, Vladimir From volker.simonis at gmail.com Sat Jan 25 01:53:01 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 25 Jan 2014 10:53:01 +0100 Subject: Merging ppc64 port into jdk9 In-Reply-To: <52E2E5F6.7060703@oracle.com> References: <52E2E5F6.7060703@oracle.com> Message-ID: On Friday, January 24, 2014, Vladimir Kozlov wrote: > Hi, > > I am waiting approval from SQE and start thinking about merge itself. > > I think the best would be to merge into one of our group repos, for > example jdk9/hs-comp, to get extensive Nightly and other testing before > propagating into jdk9 master. > > The main question for me is what about jdk and top dir changes? They will > not be tested until they are propagated into jdk9/dev. > What do you mean by "they will not be tested"? Don't you build full JDKs for the hs group repos? Or do mean that you only run HS-specific tests for those repos (i.e. don't you run the same JPRT runs like for the jdk9/dev repo)? Nevertheless that would be at least a kind of build and smoke testing for the complete port, right? And we would have a chance to fix PPC-specific problems after the merge right away in the group repository before they arrive in jdk9/dev. I think my main concerns are that the integration may not cleanly resolve or that it will result in build failures. Besides these problems, I agree that testing the HotSpot should be the main priority. I don't expect problems in the class library, once everything resolves and builds cleanly. All that said, I'd prefer to integrate the complete port into one forest, but of course it's up to you. > Is it possible to split the merge and push Hotspot changes into > jdk9/hs-comp/hotspot and the rest into jdk9/dev? > > I don't remember that we have introduced any dependencies on your platforms. But of course we won't be able to do any testing on our platforms until hs-comp will be integrated into jdk9/dev. > I will try to do JPRT control run of stage-9 without Hotspot changes. I guess that should work but I'm also interested in the actual results of that run. > thanks, > Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140125/d0c87227/attachment.html From vladimir.kozlov at oracle.com Sat Jan 25 08:37:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 25 Jan 2014 08:37:51 -0800 Subject: Merging ppc64 port into jdk9 In-Reply-To: References: <52E2E5F6.7060703@oracle.com> Message-ID: <52E3E85F.4020406@oracle.com> JPRT control run of stage-9 without Hotspot changes went well - no problems. Also when JPRT pushes only Hotspot changes into ppc64 stage it use our promoted JDK. Which means separate Hotspot changes work too. So we can separate them but as you said it is better to push it into one forest. We don't build full forest for hotspot repos testing. We testing Hotspot changes by putting VM into the latest promoted jdk. When the process was designed long ago the assumption was that Hotspot group does not touch libraries. It bites us several times already because changes in library or Hotspot may affect each other and we notice that only after integration into master. In jdk9 and following we are trying to solve that problem. That is why we reduced total number of jdk9 repositories. An other reason to push jdk changes directly into jdk9/dev is generated-configure.sh. Nobody in Hotspot team has experience with its merge because we never had to do it. So I am worrying about that because it is not simple process as you remember. Regards, Vladimir On 1/25/14 1:53 AM, Volker Simonis wrote: > > > On Friday, January 24, 2014, Vladimir Kozlov > wrote: > > Hi, > > I am waiting approval from SQE and start thinking about merge itself. > > I think the best would be to merge into one of our group repos, for example jdk9/hs-comp, to get extensive Nightly > and other testing before propagating into jdk9 master. > > The main question for me is what about jdk and top dir changes? They will not be tested until they are propagated > into jdk9/dev. > > > What do you mean by "they will not be tested"? Don't you build full JDKs for the hs group repos? Or do mean that you > only run HS-specific tests for those repos (i.e. don't you run the same JPRT runs like for the jdk9/dev repo)? > Nevertheless that would be at least a kind of build and smoke testing for the complete port, right? > And we would have a chance to fix PPC-specific problems after the merge right away in the group repository before they > arrive in jdk9/dev. > > I think my main concerns are that the integration may not cleanly resolve or that it will result in build failures. > Besides these problems, I agree that testing the HotSpot should be the main priority. I don't expect problems in the > class library, once everything resolves and builds cleanly. > > All that said, I'd prefer to integrate the complete port into one forest, but of course it's up to you. > > Is it possible to split the merge and push Hotspot changes into jdk9/hs-comp/hotspot and the rest into jdk9/dev? > > > I don't remember that we have introduced any dependencies on your platforms. But of course we won't be able to do any > testing on our platforms until hs-comp will be integrated into jdk9/dev. > > I will try to do JPRT control run of stage-9 without Hotspot changes. > > > I guess that should work but I'm also interested in the actual results of that run. > > > thanks, > Vladimir > From vladimir.kozlov at oracle.com Sat Jan 25 14:24:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 25 Jan 2014 14:24:22 -0800 Subject: Merging ppc64 port into jdk9 In-Reply-To: <52E3E85F.4020406@oracle.com> References: <52E2E5F6.7060703@oracle.com> <52E3E85F.4020406@oracle.com> Message-ID: <52E43996.3030203@oracle.com> How about I push jdk changes into jdk9/dev and pull it down into jdk9/hs-comp? This ways you will get whole ppc64 forest in hs-comp, we get testing of jdk changes and we avoid jdk merge problems for our gatekeepers. Thanks, Vladimir On 1/25/14 8:37 AM, Vladimir Kozlov wrote: > JPRT control run of stage-9 without Hotspot changes went well - no problems. Also when JPRT pushes only Hotspot changes > into ppc64 stage it use our promoted JDK. Which means separate Hotspot changes work too. So we can separate them but as > you said it is better to push it into one forest. > > We don't build full forest for hotspot repos testing. We testing Hotspot changes by putting VM into the latest promoted > jdk. When the process was designed long ago the assumption was that Hotspot group does not touch libraries. It bites us > several times already because changes in library or Hotspot may affect each other and we notice that only after > integration into master. In jdk9 and following we are trying to solve that problem. That is why we reduced total number > of jdk9 repositories. > > An other reason to push jdk changes directly into jdk9/dev is generated-configure.sh. Nobody in Hotspot team has > experience with its merge because we never had to do it. So I am worrying about that because it is not simple process as > you remember. > > Regards, > Vladimir > > On 1/25/14 1:53 AM, Volker Simonis wrote: >> >> >> On Friday, January 24, 2014, Vladimir Kozlov > wrote: >> >> Hi, >> >> I am waiting approval from SQE and start thinking about merge itself. >> >> I think the best would be to merge into one of our group repos, for example jdk9/hs-comp, to get extensive Nightly >> and other testing before propagating into jdk9 master. >> >> The main question for me is what about jdk and top dir changes? They will not be tested until they are propagated >> into jdk9/dev. >> >> >> What do you mean by "they will not be tested"? Don't you build full JDKs for the hs group repos? Or do mean that you >> only run HS-specific tests for those repos (i.e. don't you run the same JPRT runs like for the jdk9/dev repo)? >> Nevertheless that would be at least a kind of build and smoke testing for the complete port, right? >> And we would have a chance to fix PPC-specific problems after the merge right away in the group repository before they >> arrive in jdk9/dev. >> >> I think my main concerns are that the integration may not cleanly resolve or that it will result in build failures. >> Besides these problems, I agree that testing the HotSpot should be the main priority. I don't expect problems in the >> class library, once everything resolves and builds cleanly. >> >> All that said, I'd prefer to integrate the complete port into one forest, but of course it's up to you. >> >> Is it possible to split the merge and push Hotspot changes into jdk9/hs-comp/hotspot and the rest into jdk9/dev? >> >> >> I don't remember that we have introduced any dependencies on your platforms. But of course we won't be able to do any >> testing on our platforms until hs-comp will be integrated into jdk9/dev. >> >> I will try to do JPRT control run of stage-9 without Hotspot changes. >> >> >> I guess that should work but I'm also interested in the actual results of that run. >> >> >> thanks, >> Vladimir >> From volker.simonis at gmail.com Sat Jan 25 14:44:09 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 25 Jan 2014 23:44:09 +0100 Subject: Merging ppc64 port into jdk9 In-Reply-To: <52E3E85F.4020406@oracle.com> References: <52E2E5F6.7060703@oracle.com> <52E3E85F.4020406@oracle.com> Message-ID: On Saturday, January 25, 2014, Vladimir Kozlov wrote: > JPRT control run of stage-9 without Hotspot changes went well - no > problems. Also when JPRT pushes only Hotspot changes into ppc64 stage it > use our promoted JDK. Which means separate Hotspot changes work too. That's good to know anyway. > So we can separate them but as you said it is better to push it into one > forest. That would be great. > > We don't build full forest for hotspot repos testing. We testing Hotspot > changes by putting VM into the latest promoted jdk. When the process was > designed long ago the assumption was that Hotspot group does not touch > libraries. It bites us several times already because changes in library or > Hotspot may affect each other and we notice that only after integration > into master. In jdk9 and following we are trying to solve that problem. > That is why we reduced total number of jdk9 repositories. > > Thanks for the explanation. > An other reason to push jdk changes directly into jdk9/dev is > generated-configure.sh. Nobody in Hotspot team has experience with its > merge because we never had to do it. So I am worrying about that because it > is not simple process as you remember. > > Fortunately, there have been not many changes in the top-level make/configure directories in the last time (the last one was the move of the makefiles from the 'makefiles/' to the 'make/' directory and even that went pretty smooth). Also, after everybody settled down to use autoconf 2.69, changes in generated-configure.sh became more manageable. So I think that if you can cleanly merge the common/ and make/ directories and recreate generated-configure.sh you should see a meaningful and reasonable diff compared to the original generated-configure.sh. And if that's the case, I'm pretty sure everything will be fine:) What about pushing all the changes to jdk9/client? We could test the whole port there without potentially breaking jdk9/dev. Regards, Volker > Regards, > Vladimir > > On 1/25/14 1:53 AM, Volker Simonis wrote: > >> >> >> On Friday, January 24, 2014, Vladimir Kozlov > vladimir.kozlov at oracle.com>> wrote: >> >> Hi, >> >> I am waiting approval from SQE and start thinking about merge itself. >> >> I think the best would be to merge into one of our group repos, for >> example jdk9/hs-comp, to get extensive Nightly >> and other testing before propagating into jdk9 master. >> >> The main question for me is what about jdk and top dir changes? They >> will not be tested until they are propagated >> into jdk9/dev. >> >> >> What do you mean by "they will not be tested"? Don't you build full JDKs >> for the hs group repos? Or do mean that you >> only run HS-specific tests for those repos (i.e. don't you run the same >> JPRT runs like for the jdk9/dev repo)? >> Nevertheless that would be at least a kind of build and smoke testing for >> the complete port, right? >> And we would have a chance to fix PPC-specific problems after the merge >> right away in the group repository before they >> arrive in jdk9/dev. >> >> I think my main concerns are that the integration may not cleanly resolve >> or that it will result in build failures. >> Besides these problems, I agree that testing the HotSpot should be the >> main priority. I don't expect problems in the >> class library, once everything resolves and builds cleanly. >> >> All that said, I'd prefer to integrate the complete port into one forest, >> but of course it's up to you. >> >> Is it possible to split the merge and push Hotspot changes into >> jdk9/hs-comp/hotspot and the rest into jdk9/dev? >> >> >> I don't remember that we have introduced any dependencies on your >> platforms. But of course we won't be able to do any >> testing on our platforms until hs-comp will be integrated into jdk9/dev. >> >> I will try to do JPRT control run of stage-9 without Hotspot changes. >> >> >> I guess that should work but I'm also interested in the actual results of >> that run. >> >> >> thanks, >> Vladimir >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140125/e5395362/attachment.html From vladimir.kozlov at oracle.com Sat Jan 25 15:15:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 25 Jan 2014 15:15:40 -0800 Subject: Merging ppc64 port into jdk9 In-Reply-To: References: <52E2E5F6.7060703@oracle.com> <52E3E85F.4020406@oracle.com> Message-ID: <52E4459C.3000901@oracle.com> > So I think that if you can cleanly merge the common/ and make/ directories and recreate generated-configure.sh you > should see a meaningful and reasonable diff compared to the original generated-configure.sh. And if that's the case, I'm > pretty sure everything will be fine:) The problem is that you need to run manually a script to regenerate open and closed (!) generated-configure.sh and do some tricks with mercurial to mark these files as resolved. You can't merge it because you need to put new timestamp. I had to do it again during latest sync. And I don't want to explain our gatekeeprs how to do that, I would prefer to do it myself to avoid screwed-up. > > What about pushing all the changes to jdk9/client? We could test the whole port there without potentially breaking jdk9/dev. jdk9/client does not test Hotspot as we do. We run several orders more VM tests. I more incline to my latest proposal to push jdk changes into jdk9/dev, pull it down to hotspot repos and push Hotspot changes into hs-comp. Regards, Vladimir On 1/25/14 2:44 PM, Volker Simonis wrote: > > > On Saturday, January 25, 2014, Vladimir Kozlov > wrote: > > JPRT control run of stage-9 without Hotspot changes went well - no problems. Also when JPRT pushes only Hotspot > changes into ppc64 stage it use our promoted JDK. Which means separate Hotspot changes work too. > > > That's good to know anyway. > > So we can separate them but as you said it is better to push it into one forest. > > > That would be great. > > > We don't build full forest for hotspot repos testing. We testing Hotspot changes by putting VM into the latest > promoted jdk. When the process was designed long ago the assumption was that Hotspot group does not touch libraries. > It bites us several times already because changes in library or Hotspot may affect each other and we notice that > only after integration into master. In jdk9 and following we are trying to solve that problem. That is why we > reduced total number of jdk9 repositories. > > > Thanks for the explanation. > > An other reason to push jdk changes directly into jdk9/dev is generated-configure.sh. Nobody in Hotspot team has > experience with its merge because we never had to do it. So I am worrying about that because it is not simple > process as you remember. > > > Fortunately, there have been not many changes in the top-level make/configure directories in the last time (the last one > was the move of the makefiles from the 'makefiles/' to the 'make/' directory and even that went pretty smooth). Also, > after everybody settled down to use autoconf 2.69, changes in generated-configure.sh became more manageable. > > So I think that if you can cleanly merge the common/ and make/ directories and recreate generated-configure.sh you > should see a meaningful and reasonable diff compared to the original generated-configure.sh. And if that's the case, I'm > pretty sure everything will be fine:) > > What about pushing all the changes to jdk9/client? We could test the whole port there without potentially breaking jdk9/dev. > > Regards, > Volker > > Regards, > Vladimir > > On 1/25/14 1:53 AM, Volker Simonis wrote: > > > > On Friday, January 24, 2014, Vladimir Kozlov > wrote: > > Hi, > > I am waiting approval from SQE and start thinking about merge itself. > > I think the best would be to merge into one of our group repos, for example jdk9/hs-comp, to get extensive > Nightly > and other testing before propagating into jdk9 master. > > The main question for me is what about jdk and top dir changes? They will not be tested until they are > propagated > into jdk9/dev. > > > What do you mean by "they will not be tested"? Don't you build full JDKs for the hs group repos? Or do mean that you > only run HS-specific tests for those repos (i.e. don't you run the same JPRT runs like for the jdk9/dev repo)? > Nevertheless that would be at least a kind of build and smoke testing for the complete port, right? > And we would have a chance to fix PPC-specific problems after the merge right away in the group repository > before they > arrive in jdk9/dev. > > I think my main concerns are that the integration may not cleanly resolve or that it will result in build failures. > Besides these problems, I agree that testing the HotSpot should be the main priority. I don't expect problems in the > class library, once everything resolves and builds cleanly. > > All that said, I'd prefer to integrate the complete port into one forest, but of course it's up to you. > > Is it possible to split the merge and push Hotspot changes into jdk9/hs-comp/hotspot and the rest into > jdk9/dev? > > > I don't remember that we have introduced any dependencies on your platforms. But of course we won't be able to > do any > testing on our platforms until hs-comp will be integrated into jdk9/dev. > > I will try to do JPRT control run of stage-9 without Hotspot changes. > > > I guess that should work but I'm also interested in the actual results of that run. > > > thanks, > Vladimir > From volker.simonis at gmail.com Sun Jan 26 15:17:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Jan 2014 00:17:26 +0100 Subject: Merging ppc64 port into jdk9 In-Reply-To: <52E4459C.3000901@oracle.com> References: <52E2E5F6.7060703@oracle.com> <52E3E85F.4020406@oracle.com> <52E4459C.3000901@oracle.com> Message-ID: On Sunday, January 26, 2014, Vladimir Kozlov wrote: > > So I think that if you can cleanly merge the common/ and make/ > directories and recreate generated-configure.sh you > > should see a meaningful and reasonable diff compared to the original > generated-configure.sh. And if that's the case, I'm > > pretty sure everything will be fine:) > > The problem is that you need to run manually a script to regenerate open > and closed (!) generated-configure.sh and do some tricks with mercurial to > mark these files as resolved. You can't merge it because you need to put > new timestamp. I had to do it again during latest sync. And I don't want to > explain our gatekeeprs how to do that, I would prefer to do it myself to > avoid screwed-up. > > > > > What about pushing all the changes to jdk9/client? We could test the > whole port there without potentially breaking jdk9/dev. > > jdk9/client does not test Hotspot as we do. We run several orders more VM > tests. > > I more incline to my latest proposal to push jdk changes into jdk9/dev, > pull it down to hotspot repos and push Hotspot changes into hs-comp. > > OK, after having discussed all the various variants, that sounds reasonable. So I'd say once you get the OK from SQE, just do it - the sooner the better (before jdk9/dev and/or hotspot move too far away from the version you tested). Regards, Volker > Regards, > Vladimir > > On 1/25/14 2:44 PM, Volker Simonis wrote: > >> >> >> On Saturday, January 25, 2014, Vladimir Kozlov < >> vladimir.kozlov at oracle.com > wrote: >> >> JPRT control run of stage-9 without Hotspot changes went well - no >> problems. Also when JPRT pushes only Hotspot >> changes into ppc64 stage it use our promoted JDK. Which means >> separate Hotspot changes work too. >> >> >> That's good to know anyway. >> >> So we can separate them but as you said it is better to push it into >> one forest. >> >> >> That would be great. >> >> >> We don't build full forest for hotspot repos testing. We testing >> Hotspot changes by putting VM into the latest >> promoted jdk. When the process was designed long ago the assumption >> was that Hotspot group does not touch libraries. >> It bites us several times already because changes in library or >> Hotspot may affect each other and we notice that >> only after integration into master. In jdk9 and following we are >> trying to solve that problem. That is why we >> reduced total number of jdk9 repositories. >> >> >> Thanks for the explanation. >> >> An other reason to push jdk changes directly into jdk9/dev is >> generated-configure.sh. Nobody in Hotspot team has >> experience with its merge because we never had to do it. So I am >> worrying about that because it is not simple >> process as you remember. >> >> >> Fortunately, there have been not many changes in the top-level >> make/configure directories in the last time (the last one >> was the move of the makefiles from the 'makefiles/' to the 'make/' >> directory and even that went pretty smooth). Also, >> after everybody settled down to use autoconf 2.69, changes in >> generated-configure.sh became more manageable. >> >> So I think that if you can cleanly merge the common/ and make/ >> directories and recreate generated-configure.sh you >> should see a meaningful and reasonable diff compared to the original >> generated-configure.sh. And if that's the case, I'm >> pretty sure everything will be fine:) >> >> What about pushing all the changes to jdk9/client? We could test the >> whole port there without potentially breaking jdk9/dev. >> >> Regards, >> Volker >> >> Regards, >> Vladimir >> >> On 1/25/14 1:53 AM, Volker Simonis wrote: >> >> >> >> On Friday, January 24, 2014, Vladimir Kozlov < >> vladimir.kozlov at oracle.com > wrote: >> >> Hi, >> >> I am waiting approval from SQE and start thinking about >> merge itself. >> >> I think the best would be to merge into one of our group >> repos, for example jdk9/hs-comp, to get extensive >> Nightly >> and other testing before propagating into jdk9 master. >> >> The main question for me is what about jdk and top dir >> changes? They will not be tested until they are >> propagated >> into jdk9/dev. >> >> >> What do you mean by "they will not be tested"? Don't you build >> full JDKs for the hs group repos? Or do mean that you >> only run HS-specific tests for those repos (i.e. don't you run >> the same JPRT runs like for the jdk9/dev repo)? >> Nevertheless that would be at least a kind of build and smoke >> testing for the complete port, right? >> And we would have a chance to fix PPC-specific problems after the >> merge right away in the group repository >> before they >> arrive in jdk9/dev. >> >> I think my main concerns are that the integration may not cleanly >> resolve or that it will result in build failures. >> Besides these problems, I agree that testing the HotSpot should >> be the main priority. I don't expect problems in the >> class library, once everything resolves and builds cleanly. >> >> All that said, I'd prefer to integrate the complete port into one >> forest, but of course it's up to you. >> >> Is it possible to split the merge and push Hotspot changes >> into jdk9/hs-comp/hotspot and the rest into >> jdk9/dev? >> >> >> I don't remember that we have introduced any dependencies on your >> platforms. But of course we won't be able to >> do any >> testing on our platforms until hs-comp will be integrated into >> jdk9/dev. >> >> I will try to do JPRT control run of stage-9 without Hotspot >> changes. >> >> >> I guess that should work but I'm also interested in the actual >> results of that run. >> >> >> thanks, >> Vladimir >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140127/f9412349/attachment.html From vladimir.kozlov at oracle.com Mon Jan 27 11:09:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 11:09:31 -0800 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <52E2A52C.3080801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E2A52C.3080801@oracle.com> Message-ID: <52E6AEEB.50701@oracle.com> I still need official reviewer for this change. Thanks, Vladimir On 1/24/14 9:38 AM, Vladimir Kozlov wrote: > Hi, > > Before the merge of ppc64 port into our main sources I have to undo this > change which simplified testing (no need for separate JPRT jobs) during > pushes into ppc64 staging repo. > > Gary Collins is working on these changes for our main sources. > > http://cr.openjdk.java.net/~kvn/8029941/webrev/ > > It will also be backported into 8u20 later. > > Thanks, > Vladimir > From roland.westrelin at oracle.com Mon Jan 27 13:36:08 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 27 Jan 2014 22:36:08 +0100 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <52E2A52C.3080801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E2A52C.3080801@oracle.com> Message-ID: <2D1479C2-F541-4B27-9630-835F39292989@oracle.com> > http://cr.openjdk.java.net/~kvn/8029941/webrev/ That looks good to me. Roland. From vladimir.kozlov at oracle.com Mon Jan 27 13:36:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 13:36:56 -0800 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <2D1479C2-F541-4B27-9630-835F39292989@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E2A52C.3080801@oracle.com> <2D1479C2-F541-4B27-9630-835F39292989@oracle.com> Message-ID: <52E6D178.6070508@oracle.com> Thank you, Roland Vladimir On 1/27/14 1:36 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8029941/webrev/ > > That looks good to me. > > Roland. > From david.holmes at oracle.com Mon Jan 27 13:44:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jan 2014 07:44:32 +1000 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <52E2A52C.3080801@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E2A52C.3080801@oracle.com> Message-ID: <52E6D340.3020601@oracle.com> Vladimir, On 25/01/2014 3:38 AM, Vladimir Kozlov wrote: > Hi, > > Before the merge of ppc64 port into our main sources I have to undo this > change which simplified testing (no need for separate JPRT jobs) during > pushes into ppc64 staging repo. I don't understand why this change is needed. Please explain the connection with PPC64. Thanks, David > Gary Collins is working on these changes for our main sources. > > http://cr.openjdk.java.net/~kvn/8029941/webrev/ > > It will also be backported into 8u20 later. > > Thanks, > Vladimir > From david.holmes at oracle.com Mon Jan 27 14:43:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jan 2014 08:43:42 +1000 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <52E6D340.3020601@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E2A52C.3080801@oracle.com> <52E6D340.3020601@oracle.com> Message-ID: <52E6E11E.2090501@oracle.com> On 28/01/2014 7:44 AM, David Holmes wrote: > Vladimir, > > On 25/01/2014 3:38 AM, Vladimir Kozlov wrote: >> Hi, >> >> Before the merge of ppc64 port into our main sources I have to undo this >> change which simplified testing (no need for separate JPRT jobs) during >> pushes into ppc64 staging repo. > > I don't understand why this change is needed. Please explain the > connection with PPC64. Okay - this was stuff merged by accident and needing cleanup. Reviewed. Thanks, David > Thanks, > David > >> Gary Collins is working on these changes for our main sources. >> >> http://cr.openjdk.java.net/~kvn/8029941/webrev/ >> >> It will also be backported into 8u20 later. >> >> Thanks, >> Vladimir >> From vladimir.kozlov at oracle.com Mon Jan 27 14:48:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Jan 2014 14:48:00 -0800 Subject: RFR (S): 8029941 PPC64: rollback changes in make/jprt.properties for embedded testing In-Reply-To: <52E6E11E.2090501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE8F92E@DEWDFEMB12A.global.corp.sap> <52E2A52C.3080801@oracle.com> <52E6D340.3020601@oracle.com> <52E6E11E.2090501@oracle.com> Message-ID: <52E6E220.6080806@oracle.com> Thank you, David Vladimir On 1/27/14 2:43 PM, David Holmes wrote: > On 28/01/2014 7:44 AM, David Holmes wrote: >> Vladimir, >> >> On 25/01/2014 3:38 AM, Vladimir Kozlov wrote: >>> Hi, >>> >>> Before the merge of ppc64 port into our main sources I have to undo this >>> change which simplified testing (no need for separate JPRT jobs) during >>> pushes into ppc64 staging repo. >> >> I don't understand why this change is needed. Please explain the >> connection with PPC64. > > Okay - this was stuff merged by accident and needing cleanup. > > Reviewed. > > Thanks, > David > > >> Thanks, >> David >> >>> Gary Collins is working on these changes for our main sources. >>> >>> http://cr.openjdk.java.net/~kvn/8029941/webrev/ >>> >>> It will also be backported into 8u20 later. >>> >>> Thanks, >>> Vladimir >>> From goetz.lindenmaier at sap.com Tue Jan 28 02:03:37 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Tue, 28 Jan 2014 10:03:37 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: Fix usage of feature detection on ppc for fsqrt instruction. Also guarantee no wrong instructions are used. Message-ID: <20140128100356.E36C3627F7@hg.openjdk.java.net> Changeset: 80893e362c98 Author: goetz Date: 2014-01-28 10:47 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/80893e362c98 Fix usage of feature detection on ppc for fsqrt instruction. Also guarantee no wrong instructions are used. ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.hpp ! src/share/vm/opto/library_call.cpp From goetz.lindenmaier at sap.com Tue Jan 28 07:36:51 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 28 Jan 2014 15:36:51 +0000 Subject: updated integration plan Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9060F@DEWDFEMB12A.global.corp.sap> Hi, I updated the "Completed" column of our integration plan. I marked M2, M3.2 and M3.3 as complete. Best regards, Goetz. https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140128/9319f1fe/attachment.html From vladimir.kozlov at oracle.com Tue Jan 28 11:33:35 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 28 Jan 2014 19:33:35 +0000 Subject: hg: ppc-aix-port/stage-9/hotspot: 8029941: rollback changes in make/jprt.properties for embedded testing Message-ID: <20140128193339.070556280D@hg.openjdk.java.net> Changeset: f0221ff14605 Author: kvn Date: 2014-01-28 10:19 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage-9/hotspot/rev/f0221ff14605 8029941: rollback changes in make/jprt.properties for embedded testing Summary: cleanup changes merged by accident Reviewed-by: roland, dholmes ! make/jprt.properties From vladimir.kozlov at oracle.com Tue Jan 28 15:49:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jan 2014 15:49:43 -0800 Subject: Hotspot part of PPC64 port was merged into jdk9 Message-ID: <52E84217.9090803@oracle.com> It was pushed into Hotspot Compiler repository for additional testing: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/ Hotspot changes: 8016476: PPC64 (part 1): reenable CORE build 8016491: PPC64 (part 2): Clean up PPC defines. 8016586: PPC64 (part 3): basic changes for PPC64 8017313: PPC64 (part 6): stack handling improvements 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking 8016696: PPC64 (part 4): add relocation for trampoline stubs 8019517: PPC64 (part 102): cppInterpreter: implement G1 support 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. 8020121: PPC64: fix build in cppInterpreter after 8019519 8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. 8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64 8019972: PPC64 (part 9): platform files for interpreter only VM. 8020775: PPC64 (part 12): posix signal printing 8023033: PPC64 (part 13): basic changes for AIX 8024379: Adapt PPC64 port to 8003424 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support 8024344: PPC64 (part 112): C argument in register AND stack slot. 8024469: PPC64 (part 202): cppInterpreter: support for OSR. 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling 8026487: PPC64: Implement 'os::fork_and_exec' on AIX 8027964: Adapt PPC to 6843347: Boundary values in some public GC options cause crashes 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops 8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes after register allocation 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering 8028401: PPC (part 117): Improve usability of adlc and format() functionality. 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' 8028580: PPC64 (part 114/120): Support for Call nodes with constants. 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. 8028767: PPC64: (part 121): smaller shared changes needed to build C2 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. 8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence. 8029015: PPC64 (part 216): opto: trap based null and range checks 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function descriptor tables 8029396: PPC64 (part 212): Several memory ordering fixes in C-code. 8029888: PPC64: (part 219): adl replacement variable CondRegister 8029940: PPC64 (part 122): C2 compiler port 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization 8030863: PPC64: (part 220): ConstantTableBase for calls between args and jvms 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks 8031319: PPC64: Some fixes in ppc and aix coding. 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. 8029941: rollback changes in make/jprt.properties for embedded testing From david.holmes at oracle.com Tue Jan 28 15:55:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jan 2014 09:55:46 +1000 Subject: Hotspot part of PPC64 port was merged into jdk9 In-Reply-To: <52E84217.9090803@oracle.com> References: <52E84217.9090803@oracle.com> Message-ID: <52E84382.70609@oracle.com> On 29/01/2014 9:49 AM, Vladimir Kozlov wrote: > It was pushed into Hotspot Compiler repository for additional testing: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/ That's a big milestone! Thanks Vladimir! And thanks Goetz for your patience through all this. David ----- > Hotspot changes: > > 8016476: PPC64 (part 1): reenable CORE build > 8016491: PPC64 (part 2): Clean up PPC defines. > 8016586: PPC64 (part 3): basic changes for PPC64 > 8017313: PPC64 (part 6): stack handling improvements > 8017317: PPC64 (part 7): cppInterpreter: implement support for biased > locking > 8016696: PPC64 (part 4): add relocation for trampoline stubs > 8019517: PPC64 (part 102): cppInterpreter: implement G1 support > 8019518: PPC64 (part 103): cppInterpreter: implement support for > compressed Oops > 8019519: PPC64 (part 105): C interpreter: implement support for jvmti > early return. > 8020121: PPC64: fix build in cppInterpreter after 8019519 > 8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles > 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > 8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64 > 8019972: PPC64 (part 9): platform files for interpreter only VM. > 8020775: PPC64 (part 12): posix signal printing > 8023033: PPC64 (part 13): basic changes for AIX > 8024379: Adapt PPC64 port to 8003424 > 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles > 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support > 8024344: PPC64 (part 112): C argument in register AND stack slot. > 8024469: PPC64 (part 202): cppInterpreter: support for OSR. > 8024342: PPC64 (part 111): Support for C calling conventions that > require 64-bit ints. > 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. > 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling > 8026487: PPC64: Implement 'os::fork_and_exec' on AIX > 8027964: Adapt PPC to 6843347: Boundary values in some public GC options > cause crashes > 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace > concepts > 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call > 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic > crashes the JVM > 8027968: Adapt PPC to 8024927: Nashorn performance regression with > CompressedOops > 8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes > after register allocation > 8024921: PPC64 (part 113): Extend Load and Store nodes to know about > memory ordering > 8028401: PPC (part 117): Improve usability of adlc and format() > functionality. > 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP > on ppc64. > 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops > has limited usefulness now' > 8028580: PPC64 (part 114/120): Support for Call nodes with constants. > 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. > 8028767: PPC64: (part 121): smaller shared changes needed to build C2 > 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile > object. > 8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence. > 8029015: PPC64 (part 216): opto: trap based null and range checks > 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function > descriptor tables > 8029396: PPC64 (part 212): Several memory ordering fixes in C-code. > 8029888: PPC64: (part 219): adl replacement variable CondRegister > 8029940: PPC64 (part 122): C2 compiler port > 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object > initialization > 8030863: PPC64: (part 220): ConstantTableBase for calls between args and > jvms > 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and > range checks > 8031319: PPC64: Some fixes in ppc and aix coding. > 8029101: PPC64 (part 211): ordering of Independent Reads of Independent > Writes > 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. > 8029941: rollback changes in make/jprt.properties for embedded testing From azeem.jiva at oracle.com Tue Jan 28 16:00:51 2014 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Tue, 28 Jan 2014 16:00:51 -0800 Subject: Hotspot part of PPC64 port was merged into jdk9 In-Reply-To: <52E84217.9090803@oracle.com> References: <52E84217.9090803@oracle.com> Message-ID: Congrats on this huge accomplishment! -- Azeem Jiva @javawithjiva On Jan 28, 2014, at 3:49 PM, Vladimir Kozlov wrote: > It was pushed into Hotspot Compiler repository for additional testing: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/ > > Hotspot changes: > > 8016476: PPC64 (part 1): reenable CORE build > 8016491: PPC64 (part 2): Clean up PPC defines. > 8016586: PPC64 (part 3): basic changes for PPC64 > 8017313: PPC64 (part 6): stack handling improvements > 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking > 8016696: PPC64 (part 4): add relocation for trampoline stubs > 8019517: PPC64 (part 102): cppInterpreter: implement G1 support > 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops > 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. > 8020121: PPC64: fix build in cppInterpreter after 8019519 > 8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles > 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. > 8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64 > 8019972: PPC64 (part 9): platform files for interpreter only VM. > 8020775: PPC64 (part 12): posix signal printing > 8023033: PPC64 (part 13): basic changes for AIX > 8024379: Adapt PPC64 port to 8003424 > 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles > 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support > 8024344: PPC64 (part 112): C argument in register AND stack slot. > 8024469: PPC64 (part 202): cppInterpreter: support for OSR. > 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. > 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. > 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling > 8026487: PPC64: Implement 'os::fork_and_exec' on AIX > 8027964: Adapt PPC to 6843347: Boundary values in some public GC options cause crashes > 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts > 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call > 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM > 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops > 8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes after register allocation > 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering > 8028401: PPC (part 117): Improve usability of adlc and format() functionality. > 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. > 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' > 8028580: PPC64 (part 114/120): Support for Call nodes with constants. > 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. > 8028767: PPC64: (part 121): smaller shared changes needed to build C2 > 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. > 8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence. > 8029015: PPC64 (part 216): opto: trap based null and range checks > 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function descriptor tables > 8029396: PPC64 (part 212): Several memory ordering fixes in C-code. > 8029888: PPC64: (part 219): adl replacement variable CondRegister > 8029940: PPC64 (part 122): C2 compiler port > 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization > 8030863: PPC64: (part 220): ConstantTableBase for calls between args and jvms > 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks > 8031319: PPC64: Some fixes in ppc and aix coding. > 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. > 8029941: rollback changes in make/jprt.properties for embedded testing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140128/f81b03fc/attachment.html From vladimir.kozlov at oracle.com Tue Jan 28 16:57:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jan 2014 16:57:27 -0800 Subject: JDK part of PPC64 port was merged into jdk9 Message-ID: <52E851F7.6060603@oracle.com> It was pushed into jdk9/dev forest: http://hg.openjdk.java.net/jdk9/dev Hotspot part of the port was pushed into jdk9/hs-comp/hotspot JDK changes: 8017568: PPC64: Generic build preparations needed to enable new build on Linux/PPC64 8024265: Enable new build on AIX 8024900: PPC64: Enable new build on AIX (jdk part) 8028066: PPC64: 8025715 changes broke AIX build after sync 8024854: PPC64: Basic changes and files to build the class library on AIX 8029669: PPC64: 8027566 changes broke AIX build after sync 8028537: PPC64: Updated the JDK regression tests to run on AIX 8031134: PPC64: implement printing on AIX 8031997: PPC64: Make the various POLL constants system dependant 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests From vladimir.kozlov at oracle.com Tue Jan 28 20:27:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jan 2014 20:27:25 -0800 Subject: JDK part of PPC64 port was merged into jdk9 In-Reply-To: <52E851F7.6060603@oracle.com> References: <52E851F7.6060603@oracle.com> Message-ID: <52E8832D.6020805@oracle.com> JDK changes also pushed into hs-comp forest which now has all ppc64 changes: http://hg.openjdk.java.net/jdk9/hs-comp Regards, Vladimir On 1/28/14 4:57 PM, Vladimir Kozlov wrote: > It was pushed into jdk9/dev forest: > > http://hg.openjdk.java.net/jdk9/dev > > Hotspot part of the port was pushed into jdk9/hs-comp/hotspot > > JDK changes: > > 8017568: PPC64: Generic build preparations needed to enable new build on > Linux/PPC64 > 8024265: Enable new build on AIX > 8024900: PPC64: Enable new build on AIX (jdk part) > 8028066: PPC64: 8025715 changes broke AIX build after sync > 8024854: PPC64: Basic changes and files to build the class library on AIX > 8029669: PPC64: 8027566 changes broke AIX build after sync > 8028537: PPC64: Updated the JDK regression tests to run on AIX > 8031134: PPC64: implement printing on AIX > 8031997: PPC64: Make the various POLL constants system dependant > 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests From volker.simonis at gmail.com Tue Jan 28 21:40:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jan 2014 06:40:52 +0100 Subject: JDK part of PPC64 port was merged into jdk9 In-Reply-To: <52E8832D.6020805@oracle.com> References: <52E851F7.6060603@oracle.com> <52E8832D.6020805@oracle.com> Message-ID: Thanks Vladimir, all this wouldn't have been possible without your help! Regards, Volker On Wednesday, January 29, 2014, Vladimir Kozlov wrote: > JDK changes also pushed into hs-comp forest which now has all ppc64 > changes: > > http://hg.openjdk.java.net/jdk9/hs-comp > > Regards, > Vladimir > > On 1/28/14 4:57 PM, Vladimir Kozlov wrote: > >> It was pushed into jdk9/dev forest: >> >> http://hg.openjdk.java.net/jdk9/dev >> >> Hotspot part of the port was pushed into jdk9/hs-comp/hotspot >> >> JDK changes: >> >> 8017568: PPC64: Generic build preparations needed to enable new build on >> Linux/PPC64 >> 8024265: Enable new build on AIX >> 8024900: PPC64: Enable new build on AIX (jdk part) >> 8028066: PPC64: 8025715 changes broke AIX build after sync >> 8024854: PPC64: Basic changes and files to build the class library on AIX >> 8029669: PPC64: 8027566 changes broke AIX build after sync >> 8028537: PPC64: Updated the JDK regression tests to run on AIX >> 8031134: PPC64: implement printing on AIX >> 8031997: PPC64: Make the various POLL constants system dependant >> 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140129/c020b9a6/attachment.html From goetz.lindenmaier at sap.com Tue Jan 28 23:59:15 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 29 Jan 2014 07:59:15 +0000 Subject: JDK part of PPC64 port was merged into jdk9 In-Reply-To: <52E851F7.6060603@oracle.com> References: <52E851F7.6060603@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE90A0A@DEWDFEMB12A.global.corp.sap> Hi everybody, that's great news!! Unbelievable! What a surprise this morning! Thanks Vladimir, Azeem, Iris, IBM, all the reviewers and people on the port team and in the background for making this happen! Cheeeers! Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Mittwoch, 29. Januar 2014 01:57 To: jdk9-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: JDK part of PPC64 port was merged into jdk9 It was pushed into jdk9/dev forest: http://hg.openjdk.java.net/jdk9/dev Hotspot part of the port was pushed into jdk9/hs-comp/hotspot JDK changes: 8017568: PPC64: Generic build preparations needed to enable new build on Linux/PPC64 8024265: Enable new build on AIX 8024900: PPC64: Enable new build on AIX (jdk part) 8028066: PPC64: 8025715 changes broke AIX build after sync 8024854: PPC64: Basic changes and files to build the class library on AIX 8029669: PPC64: 8027566 changes broke AIX build after sync 8028537: PPC64: Updated the JDK regression tests to run on AIX 8031134: PPC64: implement printing on AIX 8031997: PPC64: Make the various POLL constants system dependant 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests From goetz.lindenmaier at sap.com Wed Jan 29 03:50:13 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 29 Jan 2014 11:50:13 +0000 Subject: RFR (XS): 8033117: PPC64: Adapt to 8002074: Support for AES on SPARC Message-ID: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap> Hi, The ppc port must implement Matcher::pass_original_key_for_aes() introduced to jdk9 after the last merge to the staging repo. Please review http://cr.openjdk.java.net/~goetz/webrevs/8033117-1-aes/ for jdk9/hs-comp and also for downport to ppc-aix-port/stage which will be integrated to jdk8u at some point. The change affects only ppc64 files. Thanks and best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140129/75d8e394/attachment.html From volker.simonis at gmail.com Wed Jan 29 06:22:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jan 2014 15:22:13 +0100 Subject: Please change ppc-aix-port/jdk8 and ppc-aix-port/stage-9 to read-only mode Message-ID: Hi Iris, if nobody minds, I'd like to suggest to switch the two repositories: ppc-aix-port/stage-9 ppc-aix-port/jdk8 to read-only mode. 'ppc-aix-port/stage-9' is not needed anymore after it has been merged into jdk9/dev and 'ppc-aix-port/jdk8' has been superseded by 'ppc-aix-port/stage' where the work for the jdk8 version of the port now happens. Thank you and best regards, Volker From vladimir.kozlov at oracle.com Wed Jan 29 08:45:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 08:45:20 -0800 Subject: RFR (XS): 8033117: PPC64: Adapt to 8002074: Support for AES on SPARC In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE90B71@DEWDFEMB12A.global.corp.sap> Message-ID: <52E93020.6050705@oracle.com> Thanks, Goetz Changes are good. I will push it today. 8002074 is not in 8u20 yet so no need backport for now. Thanks, Vladimir On 1/29/14 3:50 AM, Lindenmaier, Goetz wrote: > Hi, > > The ppc port must implement Matcher::pass_original_key_for_aes() introduced to > jdk9 after the last merge to the staging repo. > > Please review > http://cr.openjdk.java.net/~goetz/webrevs/8033117-1-aes/ > for jdk9/hs-comp and also for downport to ppc-aix-port/stage which will > be integrated to jdk8u at some point. > > The change affects only ppc64 files. > > Thanks and best regards, > Goetz. > From iris.clark at oracle.com Wed Jan 29 09:06:58 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 29 Jan 2014 09:06:58 -0800 (PST) Subject: Please change ppc-aix-port/jdk8 and ppc-aix-port/stage-9 to read-only mode In-Reply-To: References: Message-ID: <1f9278e4-a6dc-4052-b2f1-d1352d086364@default> Hi, Volker. They're read-only: http://hg.openjdk.java.net/ppc-aix-port/jdk8/ http://hg.openjdk.java.net/ppc-aix-port/stage-9/ Thanks, iris -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Wednesday, January 29, 2014 6:22 AM To: ppc-aix-port-dev at openjdk.java.net; Iris Clark Subject: Please change ppc-aix-port/jdk8 and ppc-aix-port/stage-9 to read-only mode Hi Iris, if nobody minds, I'd like to suggest to switch the two repositories: ppc-aix-port/stage-9 ppc-aix-port/jdk8 to read-only mode. 'ppc-aix-port/stage-9' is not needed anymore after it has been merged into jdk9/dev and 'ppc-aix-port/jdk8' has been superseded by 'ppc-aix-port/stage' where the work for the jdk8 version of the port now happens. Thank you and best regards, Volker From volker.simonis at gmail.com Wed Jan 29 09:59:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jan 2014 18:59:27 +0100 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev Message-ID: Hi, please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8033154/ which fixes the AIX build after the integration of ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. I would ideally like to push this change to jdk9/hs-comp/jdk because that's the only repository where there's currently a complete AIX port. However if that is not possible, I'll push it to jdk9/dev/jdk and wait until it gets synced with jdk9/hs-comp again. Please notice that this change is also intended for downport into 8u, but I don't expect this to be a problem because it only contains AIX-specific coding. The main problem with the integration was caused by change "8032451: (dc) DatagramChannel.join should support include-mode filtering on OS X" which was already in jdk9/dev/jdk but not in ppc-aix-port/stage-9/jdk. It caused some issues which will be solved with this change: make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c 8032451 did some changes to NativeThread.c. Instead of adding another platform specific section to that file I've moved the AIX implementation to it's own file which will only be used during the AIX port. Notice that the changes in the makefile are in a AIX-specific section and won't affect any other platform. src/solaris/native/sun/nio/ch/Net.c 8032451 removed some specific coding which was used by AIX as well. To re-enable the build on AIX 5.3 we have to define the two structures 'ip_mreq_source' and 'group_source_req' on that platform. src/solaris/classes/sun/net/PortConfig.java This is another file which wasn't present in our stage-9/jdk repository but in the new jdk9/dev/jdk. Just added the required, AIX-specific section to the file. src/share/lib/security/java.security-aix Recent changes have updated the various src/share/lib/security/java.security* files. Without these changes, the JDK failes to pass the java/lang/SecurityManager/CheckPackageAccess.java jtreg regression test. I've just updated java.security-aix to be the same like the corresponding Linux version (as this was done - and agreed upon that it is OK - in the initial AIX change). Regards, Volker From vladimir.kozlov at oracle.com Wed Jan 29 10:10:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 10:10:11 -0800 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev In-Reply-To: References: Message-ID: <52E94403.60704@oracle.com> On 1/29/14 9:59 AM, Volker Simonis wrote: > Hi, > > please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8033154/ > > which fixes the AIX build after the integration of > ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. > > I would ideally like to push this change to jdk9/hs-comp/jdk because > that's the only repository where there's currently a complete AIX > port. However if that is not possible, I'll push it to jdk9/dev/jdk > and wait until it gets synced with jdk9/hs-comp again. I don't see a problem to push into jdk9/hs-comp/jdk. It is even better for me since I have to prepare new control builds of whole forest for testing and I can get sources for that from one place. The only reason to push fix into jdk9/dev/jdk if something breaks builds on our platforms, I think. You can pushed into jdk9/hs-comp/jdk after reviews. Thanks, Vladimir > > Please notice that this change is also intended for downport into 8u, > but I don't expect this to be a problem because it only contains > AIX-specific coding. > > The main problem with the integration was caused by change "8032451: > (dc) DatagramChannel.join should support include-mode filtering on OS > X" which was already in jdk9/dev/jdk but not in > ppc-aix-port/stage-9/jdk. It caused some issues which will be solved > with this change: > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > 8032451 did some changes to NativeThread.c. Instead of adding another > platform specific section to that file I've moved the AIX > implementation to it's own file which will only be used during the AIX > port. Notice that the changes in the makefile are in a AIX-specific > section and won't affect any other platform. > > > src/solaris/native/sun/nio/ch/Net.c > > 8032451 removed some specific coding which was used by AIX as well. To > re-enable the build on AIX 5.3 we have to define the two structures > 'ip_mreq_source' and 'group_source_req' on that platform. > > > src/solaris/classes/sun/net/PortConfig.java > > This is another file which wasn't present in our stage-9/jdk > repository but in the new jdk9/dev/jdk. Just added the required, > AIX-specific section to the file. > > > src/share/lib/security/java.security-aix > > Recent changes have updated the various > src/share/lib/security/java.security* files. Without these changes, > the JDK failes to pass the > java/lang/SecurityManager/CheckPackageAccess.java jtreg regression > test. I've just updated java.security-aix to be the same like the > corresponding Linux version (as this was done - and agreed upon that > it is OK - in the initial AIX change). > > Regards, > Volker > From Alan.Bateman at oracle.com Wed Jan 29 11:32:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Jan 2014 19:32:19 +0000 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev In-Reply-To: References: Message-ID: <52E95743.7050708@oracle.com> On 29/01/2014 17:59, Volker Simonis wrote: > Hi, > > please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8033154/ > > which fixes the AIX build after the integration of > ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. > > I would ideally like to push this change to jdk9/hs-comp/jdk because > that's the only repository where there's currently a complete AIX > port. However if that is not possible, I'll push it to jdk9/dev/jdk > and wait until it gets synced with jdk9/hs-comp again. > The changes look okay to me. An alternative to introducing AixNativeThread.c would be to just put an ifdef AIX in NativeThread.c to defined INTERRUPT_SIGNAL. I don't see any issue with this being pushed to jdk9/hs-comp. -Alan From sean.mullan at oracle.com Wed Jan 29 11:52:08 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Jan 2014 14:52:08 -0500 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev In-Reply-To: References: Message-ID: <52E95BE8.1020806@oracle.com> The java.security-aix file looks fine to me. --Sean On 01/29/2014 12:59 PM, Volker Simonis wrote: > Hi, > > please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8033154/ > > which fixes the AIX build after the integration of > ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. > > I would ideally like to push this change to jdk9/hs-comp/jdk because > that's the only repository where there's currently a complete AIX > port. However if that is not possible, I'll push it to jdk9/dev/jdk > and wait until it gets synced with jdk9/hs-comp again. > > Please notice that this change is also intended for downport into 8u, > but I don't expect this to be a problem because it only contains > AIX-specific coding. > > The main problem with the integration was caused by change "8032451: > (dc) DatagramChannel.join should support include-mode filtering on OS > X" which was already in jdk9/dev/jdk but not in > ppc-aix-port/stage-9/jdk. It caused some issues which will be solved > with this change: > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > 8032451 did some changes to NativeThread.c. Instead of adding another > platform specific section to that file I've moved the AIX > implementation to it's own file which will only be used during the AIX > port. Notice that the changes in the makefile are in a AIX-specific > section and won't affect any other platform. > > > src/solaris/native/sun/nio/ch/Net.c > > 8032451 removed some specific coding which was used by AIX as well. To > re-enable the build on AIX 5.3 we have to define the two structures > 'ip_mreq_source' and 'group_source_req' on that platform. > > > src/solaris/classes/sun/net/PortConfig.java > > This is another file which wasn't present in our stage-9/jdk > repository but in the new jdk9/dev/jdk. Just added the required, > AIX-specific section to the file. > > > src/share/lib/security/java.security-aix > > Recent changes have updated the various > src/share/lib/security/java.security* files. Without these changes, > the JDK failes to pass the > java/lang/SecurityManager/CheckPackageAccess.java jtreg regression > test. I've just updated java.security-aix to be the same like the > corresponding Linux version (as this was done - and agreed upon that > it is OK - in the initial AIX change). > > Regards, > Volker > From goetz.lindenmaier at sap.com Thu Jan 30 06:26:51 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 Jan 2014 14:26:51 +0000 Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap> Hi, Please review and test this change: http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn It fixes the warnings with gcc 4.8 when compiling adlc introduced in 8003854 with the ppc port. This also needs to be downported to jdk8u via ppc-aix-port/stage. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20140130/7fb797de/attachment.html From vladimir.kozlov at oracle.com Thu Jan 30 08:41:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jan 2014 08:41:20 -0800 Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap> Message-ID: <52EA80B0.8060001@oracle.com> Looks good. I will push it in both places. Thanks, Vladimir On 1/30/14 6:26 AM, Lindenmaier, Goetz wrote: > Hi, > > Please review and test this change: > http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn > > It fixes the warnings with gcc 4.8 when compiling adlc > introduced in 8003854 with the ppc port. > > This also needs to be downported to jdk8u via ppc-aix-port/stage. > > Best regards, > Goetz. > From gnu.andrew at redhat.com Thu Jan 30 10:34:20 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 30 Jan 2014 13:34:20 -0500 (EST) Subject: Merge of PPC port into IcedTea 2.x for OpenJDK 7 In-Reply-To: <1134378615.2032431.1391106679830.JavaMail.root@redhat.com> Message-ID: <1130124280.2033357.1391106860408.JavaMail.root@redhat.com> Hi all, I'm just about done with a merge of the PPC port into our IcedTea 2.x tree which supports OpenJDK 7 (currently u60 b03). I'd like to enable the port by default, in preference to Zero, but I'm under the impression that not all PPC64 boxes will support it. Is there a way of detecting whether the processor can support the port, via the likes of /proc/cpuinfo or cpuid? Thanks for all your hard work on this. We're already seeing much faster results than when using Zero! Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From volker.simonis at gmail.com Thu Jan 30 11:28:59 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 30 Jan 2014 20:28:59 +0100 Subject: Merge of PPC port into IcedTea 2.x for OpenJDK 7 In-Reply-To: <1130124280.2033357.1391106860408.JavaMail.root@redhat.com> References: <1134378615.2032431.1391106679830.JavaMail.root@redhat.com> <1130124280.2033357.1391106860408.JavaMail.root@redhat.com> Message-ID: Hi Andrew, nice to hear that we're finally getting consumed :) We regularly build and test on boxes with IBM's Power 5,6 and 7 CPUs. So on these machines there should be no problems. What other 64-bit Power machines do you think of? Recently, some folks from Servergy started to test our port on their new e6500 CPUs. Monica Beckwith from Servergy will be at FOSDEM so I hope we can have a chat there. If you run a debug version of java with the "?XX:+Verbose" flag, the VM will print the extra instructions it detected and it thinks are available on your machine. In general we only use Power5 instructions plus the one we detected. If you run on hardware older than Power5, we may have to do some more probing, but we don't have such machines. If you encounter any problems, please let us know. Hope to see you at FOSDEM, Volker On Thu, Jan 30, 2014 at 7:34 PM, Andrew Hughes wrote: > Hi all, > > I'm just about done with a merge of the PPC port into our IcedTea > 2.x tree which supports OpenJDK 7 (currently u60 b03). I'd like > to enable the port by default, in preference to Zero, but I'm under > the impression that not all PPC64 boxes will support it. Is there > a way of detecting whether the processor can support the port, > via the likes of /proc/cpuinfo or cpuid? > > Thanks for all your hard work on this. We're already seeing much > faster results than when using Zero! > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From vladimir.kozlov at oracle.com Thu Jan 30 13:45:19 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 30 Jan 2014 21:45:19 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 8033168: PPC64: gcc 4.8 warning in output_c.cpp Message-ID: <20140130214522.0E1A1628E4@hg.openjdk.java.net> Changeset: 2fcab8ba885a Author: goetz Date: 2014-01-30 14:30 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/2fcab8ba885a 8033168: PPC64: gcc 4.8 warning in output_c.cpp Summary: fix warnings Reviewed-by: kvn ! src/share/vm/adlc/output_c.cpp From goetz.lindenmaier at sap.com Thu Jan 30 14:28:22 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 Jan 2014 22:28:22 +0000 Subject: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp In-Reply-To: <52EA80B0.8060001@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE9152D@DEWDFEMB12A.global.corp.sap> <52EA80B0.8060001@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9172C@DEWDFEMB12A.global.corp.sap> Thanks a lot! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, January 30, 2014 5:41 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR (S): 8033168: PPC64: gcc 4.8 warning in output_c.cpp Looks good. I will push it in both places. Thanks, Vladimir On 1/30/14 6:26 AM, Lindenmaier, Goetz wrote: > Hi, > > Please review and test this change: > http://cr.openjdk.java.net/~goetz/webrevs/8033168-1-warn > > It fixes the warnings with gcc 4.8 when compiling adlc > introduced in 8003854 with the ppc port. > > This also needs to be downported to jdk8u via ppc-aix-port/stage. > > Best regards, > Goetz. >