From derek.white at oracle.com Fri Jul 1 01:18:10 2016 From: derek.white at oracle.com (Derek White) Date: Thu, 30 Jun 2016 21:18:10 -0400 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: <9485c866-ef8d-4086-2936-7e27573c3f98@oracle.com> On 6/30/16 7:17 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/src/share/vm/classfile/javaClasses.hpp.udiff.html > > http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp.udiff.html > > > Since there are no changes, can you hg revert thes file? Sure, if folding the patches doesn't do it first (I'll double check). > > http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html > > > Wow, what a small race! > > Nice fix. The code looks good. > > Coleen Thanks Colleen! > > > On 6/30/16 5:15 PM, Derek White wrote: >> New webrev goes back to using java_lang_Class::set_oop_size(new_cls, >> size); >> >> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ >> >> jprt run in progress. Built w/ and w/o PCH. >> >> On 6/30/16 7:56 AM, Derek White wrote: >>> On 6/30/16 12:28 AM, David Holmes wrote: >>>> Hi Derek, >>>> >>>> Understand the fix in principle. >>>> >>>> But I don't understand why you got rid of >>>> java_lang_Class::set_oop_size, and instead exposed >>>> java_lang_Class::oop_size_offset(), then had >>>> InstanceMirrorKlass::allocate_instance pass the offset to >>>> CollectedHeap::class_allocate, which passes it to >>>> CollectedHeap::post_allocation_setup_class - that seems rather >>>> convoluted. Can CollectedHeap::post_allocation_setup_class not call >>>> java_lang_Class::set_oop_size directly? >>> >>> Short answer is I didn't think so. collectedHeap.inline.hpp has a >>> very small include set, and I was concerned about circular >>> dependencies. Another approach would be to push ::set_oop_size() >>> over to instanceKlassMirror.hpp, and see if the includes seem saner >>> that way. I'll try some alternatives... >> >> OK, doing the simple and obvious thing worked out after all. Thanks >> David! >> >> - Derek > From david.holmes at oracle.com Fri Jul 1 02:09:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Jul 2016 12:09:57 +1000 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: <8abab997-31ec-ea9c-3e1b-5e114a14750a@oracle.com> On 1/07/2016 7:15 AM, Derek White wrote: > New webrev goes back to using java_lang_Class::set_oop_size(new_cls, size); > > http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ Much neater/simpler :) Thanks. Aside: I had no idea we could do printf style strings in asserts! When did we get that? :) Thanks, David ----- > jprt run in progress. Built w/ and w/o PCH. > > On 6/30/16 7:56 AM, Derek White wrote: >> On 6/30/16 12:28 AM, David Holmes wrote: >>> Hi Derek, >>> >>> Understand the fix in principle. >>> >>> But I don't understand why you got rid of >>> java_lang_Class::set_oop_size, and instead exposed >>> java_lang_Class::oop_size_offset(), then had >>> InstanceMirrorKlass::allocate_instance pass the offset to >>> CollectedHeap::class_allocate, which passes it to >>> CollectedHeap::post_allocation_setup_class - that seems rather >>> convoluted. Can CollectedHeap::post_allocation_setup_class not call >>> java_lang_Class::set_oop_size directly? >> >> Short answer is I didn't think so. collectedHeap.inline.hpp has a very >> small include set, and I was concerned about circular dependencies. >> Another approach would be to push ::set_oop_size() over to >> instanceKlassMirror.hpp, and see if the includes seem saner that way. >> I'll try some alternatives... > > OK, doing the simple and obvious thing worked out after all. Thanks David! > > - Derek From david.holmes at oracle.com Fri Jul 1 02:22:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Jul 2016 12:22:15 +1000 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> References: <56FBDE2F.60701@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> <233a5477-0a8c-0aac-71f5-02b1b7d9eb2e@gmail.com> <34e0b47d-8809-3d19-e788-40bb6a8fd1a4@oracle.com> <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> Message-ID: On 30/06/2016 11:13 PM, Yasumasa Suenaga wrote: > Hi Marcus, > >> Looks good, thanks for fixing this. > > Thanks! > I'm waiting a second reviewer and accepting FC extension request. Reviewed. This looks much neater. Thanks. David ----- > > Yasumasa > > > On 2016/06/30 22:10, Marcus Larsson wrote: >> Hi >> >> >> On 2016-06-30 15:01, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>>> Can we keep the printing of the index # in LogConfiguration? That >>>> would save us from passing it as a parameter to describe. (So, print >>>> index, call describe, and then print newline.) >>> >>> I've fixed it. >>> Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.07/ >> >> Looks good, thanks for fixing this. >> >> Marcus >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/30 18:38, Marcus Larsson wrote: >>>> Hi, >>>> >>>> >>>> On 2016-06-30 11:31, Yasumasa Suenaga wrote: >>>>> Hi Marcus, >>>>> >>>>>>> Therefore I suggest that we introduce a describe() function in >>>>>>> LogOutput as part of this change, and move the code currently in >>>>>>> LogConfiguration::describe to this function, adding the option >>>>>>> text to it as well. >>>>> >>>>> Ah, I understood. >>>>> If we refactor that in this enhancement, we do not need to make >>>>> dynamic memory allocation. >>>>> >>>>> I uploaded a new webrev. >>>>> I hope this webrev matches your suggestion :-) >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ >>>> >>>> Looks good! Just a nit: Can we keep the printing of the index # in >>>> LogConfiguration? That would save us from passing it as a parameter >>>> to describe. (So, print index, call describe, and then print newline.) >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/06/28 22:21, Yasumasa Suenaga wrote: >>>>>> Hi Marcus, >>>>>> >>>>>>> I don't really like that we need to make dynamic allocations here. >>>>>> >>>>>> Should use resource area? or char array? >>>>>> If we should use char array, how long should we reserve for buffer? >>>>>> >>>>>> >>>>>>> Therefore I suggest that we introduce a describe() function in >>>>>>> LogOutput as part of this change, and move the code currently in >>>>>>> LogConfiguration::describe to this function, adding the option >>>>>>> text to it as well. >>>>>> >>>>>> I think this is refactoring of LogOutput and LogConfiguration. >>>>>> Now (after FC date), is this work accepted? >>>>>> >>>>>> IMHO, refactoring is another enhancement from this. >>>>>> If it is needed, I think this enhancement should be started after >>>>>> refactoring. >>>>>> >>>>>> >>>>>> If refactoring and this enhancement can be merged and be accepted, >>>>>> I will start to work for it. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/28 20:23, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review and sponsor it? >>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>>> >>>>>>> I don't really like that we need to make dynamic allocations >>>>>>> here. I would prefer to have the outputs be responsible for >>>>>>> describing themselves just like David mentions. The current >>>>>>> design of LogConfiguration::describe doesn't follow that pattern, >>>>>>> but I really think it should. Therefore I suggest that we >>>>>>> introduce a describe() function in LogOutput as part of this >>>>>>> change, and move the code currently in LogConfiguration::describe >>>>>>> to this function, adding the option text to it as well. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> I've requested FC extension for this. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/06/13 13:24, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for your comment. >>>>>>>>>> >>>>>>>>>>> So options are a distinct property of outputs and so should >>>>>>>>>>> have been >>>>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>>> >>>>>>>>>> I agree to you. >>>>>>>>>> But I think we need to discuss about it with logging folks. >>>>>>>>>> >>>>>>>>>> I uploaded a new webrev. It removes fixed buffer length and >>>>>>>>>> changes the >>>>>>>>>> order of output. >>>>>>>>>> Could you review again? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>>>>> >>>>>>>>> It's okay to wait and hear what opinions others may have before >>>>>>>>> changing things based on my comments. :) The fixed buffer may >>>>>>>>> be okay - as I said I don't know what the potential options >>>>>>>>> are, so don't know if it is okay or not. >>>>>>>>> >>>>>>>>> Using dynamic allocation avoids that but raises other concerns >>>>>>>>> - like calling vm_exit_on_out_of_memory on failure; or whether >>>>>>>>> to use malloc or resource area? >>>>>>>>> >>>>>>>>> Lets wait for other feedback before going further. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> I think "config_string" is different from "option_string". >>>>>>>>>>>> >>>>>>>>>>>> -Xlog format (from -Xlog:help message): >>>>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>>>> >>>>>>>>>>>> config_string: "what" (ex. gc=trace) >>>>>>>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>>>>>>> >>>>>>>>>>>> Currently, LogOutput handles tags and loglevels only as >>>>>>>>>>>> config_string. >>>>>>>>>>>> It does not contain output options. >>>>>>>>>>> >>>>>>>>>>> Okay I'm starting to see the bigger picture here. In terms of >>>>>>>>>>> the >>>>>>>>>>> overall logging configuration we might have, for example: >>>>>>>>>>> >>>>>>>>>>> gc=trace -> stdout >>>>>>>>>>> runtime=info -> fileA >>>>>>>>>>> compiler=trace -> fileB >>>>>>>>>>> >>>>>>>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>>>>>>> output. So for each output we set its "configuration" to the >>>>>>>>>>> associated LHS. >>>>>>>>>>> >>>>>>>>>>> So options are a distinct property of outputs and so should >>>>>>>>>>> have been >>>>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>>>> >>>>>>>>>>> Okay so looking at your v4 I have two comments: >>>>>>>>>>> >>>>>>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the >>>>>>>>>>> possible options >>>>>>>>>>> are so don't know if 100 is adequate. >>>>>>>>>>> >>>>>>>>>>> Second, if the logging syntax is: >>>>>>>>>>> >>>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>>> >>>>>>>>>>> then shouldn't the configuration be printed in the same >>>>>>>>>>> order/format? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there some reason the option string could not simply >>>>>>>>>>>>>>> become >>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>> the existing configuration string? >>>>>>>>>>>>>> >>>>>>>>>>>>>> My first proposal keeps option string at LogOutput and its >>>>>>>>>>>>>> child class >>>>>>>>>>>>>> (See webrev.01). >>>>>>>>>>>>>> Marcus commented that option string should be generated >>>>>>>>>>>>>> from current >>>>>>>>>>>>>> configuration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry but I repeat my question - why is the option >>>>>>>>>>>>> information not >>>>>>>>>>>>> simply part of the config_string? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>>>>>>> print_option_string seems the wrong name given that the >>>>>>>>>>>>>>> base class, >>>>>>>>>>>>>>> LogOutput, has no notion of having an "option string". It >>>>>>>>>>>>>>> seems to be >>>>>>>>>>>>>>> a supposedly generic "print other stuff" function that >>>>>>>>>>>>>>> only one class >>>>>>>>>>>>>>> actually needs to implement. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Secondly it inverts the style of the API used for >>>>>>>>>>>>>>> everything else >>>>>>>>>>>>>>> - we >>>>>>>>>>>>>>> have getters for all the other "properties" which are >>>>>>>>>>>>>>> then printed by >>>>>>>>>>>>>>> the describe_current_configuration method. But this is >>>>>>>>>>>>>>> instead a >>>>>>>>>>>>>>> "print" function where we ask the target to print >>>>>>>>>>>>>>> itself. Mixing the >>>>>>>>>>>>>>> two styles seems messy. It probably would have been >>>>>>>>>>>>>>> better to have >>>>>>>>>>>>>>> had >>>>>>>>>>>>>>> a print-style API from the start - then adding the >>>>>>>>>>>>>>> options would have >>>>>>>>>>>>>>> been a trivial extension for those output classes with >>>>>>>>>>>>>>> options. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In addition the change you made to >>>>>>>>>>>>>>> describe_current_configuration is >>>>>>>>>>>>>>> not at all general purpose - you wanted a given format >>>>>>>>>>>>>>> (print between >>>>>>>>>>>>>>> the config string and the decorators) for this one class >>>>>>>>>>>>>>> and so you >>>>>>>>>>>>>>> added the code to support that format. But that format >>>>>>>>>>>>>>> may not make >>>>>>>>>>>>>>> sense for other classes that might have "extra stuff" to >>>>>>>>>>>>>>> print. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there some reason the option string could not simply >>>>>>>>>>>>>>> become >>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>> the existing configuration string? It seems to me that >>>>>>>>>>>>>>> for a LogFile >>>>>>>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PS. The two hpp files would need their copyright years >>>>>>>>>>>>>>> updated to >>>>>>>>>>>>>>> "2015, 2016,". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This change is small fix, and it helps us to confirm >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/05/10 8:06, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016/05/04 23:38, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 05/04/2016 04:12 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT >>>>>>>>>>>>>>>>>>>>> "%s ", >>>>>>>>>>>>>>>>>>>>> _file_count, byte_size_in_proper_unit(_rotate_size), >>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size(_rotate_size)); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, I applied it to new webrev: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Looks OK. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2016/05/04 22:35, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Looks better. The format for _rotate_size should be >>>>>>>>>>>>>>>>>>>>> SIZE_FORMAT. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> While we're at it I think it would be good (as I >>>>>>>>>>>>>>>>>>>>> mentioned) to >>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>> a proper unit for the filesize. Basically changing >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=%lu ", >>>>>>>>>>>>>>>>>>>>> _file_count, >>>>>>>>>>>>>>>>>>>>> _rotate_size); >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT >>>>>>>>>>>>>>>>>>>>> "%s ", >>>>>>>>>>>>>>>>>>>>> _file_count, byte_size_in_proper_unit(_rotate_size), >>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size(_rotate_size)); >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I fixed to use _rotate_size and _file_count >>>>>>>>>>>>>>>>>>>>>> directly to show >>>>>>>>>>>>>>>>>>>>>> VM.log list jcmd. >>>>>>>>>>>>>>>>>>>>>> I do not store option string, and I added new >>>>>>>>>>>>>>>>>>>>>> function to >>>>>>>>>>>>>>>>>>>>>> print >>>>>>>>>>>>>>>>>>>>>> option string. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Could you review it again? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 2016/05/04 18:33, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I would prefer to generate the option string from >>>>>>>>>>>>>>>>>>>>>>> the actual >>>>>>>>>>>>>>>>>>>>>>> options rather than saving the string from when >>>>>>>>>>>>>>>>>>>>>>> it was >>>>>>>>>>>>>>>>>>>>>>> configured. This would also produce/print the >>>>>>>>>>>>>>>>>>>>>>> options for >>>>>>>>>>>>>>>>>>>>>>> outputs that are using the defaults (which is not >>>>>>>>>>>>>>>>>>>>>>> the case >>>>>>>>>>>>>>>>>>>>>>> now). >>>>>>>>>>>>>>>>>>>>>>> The filesize option could then use >>>>>>>>>>>>>>>>>>>>>>> byte_size_in_proper_unit and >>>>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size to make it easier to read. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Also, get_option_string() should just be called >>>>>>>>>>>>>>>>>>>>>>> option_string(). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This patch makes to show option string of >>>>>>>>>>>>>>>>>>>>>>>> LogFileOutput. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>> I adapted changes to jdk9/hs/hotspot repos. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Please review. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> PING: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I've sent review request for JDK-8153074. >>>>>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> If this patch is merged, user can confirm >>>>>>>>>>>>>>>>>>>>>>>>>> output option >>>>>>>>>>>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>>>>>>>>>>> VM.log jcmd. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Please review and sponsor it. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I want to see output option (filecount, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> filesize) in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> VM.log jcmd. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output sample: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #2: gc.log gc=trace, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> filecount=5,filesize=1048576 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> time,level, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> >>>> >> From yasuenag at gmail.com Fri Jul 1 03:16:07 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Jul 2016 12:16:07 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> <233a5477-0a8c-0aac-71f5-02b1b7d9eb2e@gmail.com> <34e0b47d-8809-3d19-e788-40bb6a8fd1a4@oracle.com> <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> Message-ID: Thanks David! I'm waiting to approve FC extension request. Marcus, David, could you be a sponsor for this? Yasumasa 2016/07/01 11:22 "David Holmes" : > On 30/06/2016 11:13 PM, Yasumasa Suenaga wrote: > >> Hi Marcus, >> >> Looks good, thanks for fixing this. >>> >> >> Thanks! >> I'm waiting a second reviewer and accepting FC extension request. >> > > Reviewed. This looks much neater. Thanks. > > David > ----- > > > >> Yasumasa >> >> >> On 2016/06/30 22:10, Marcus Larsson wrote: >> >>> Hi >>> >>> >>> On 2016-06-30 15:01, Yasumasa Suenaga wrote: >>> >>>> Hi Marcus, >>>> >>>> Can we keep the printing of the index # in LogConfiguration? That >>>>> would save us from passing it as a parameter to describe. (So, print >>>>> index, call describe, and then print newline.) >>>>> >>>> >>>> I've fixed it. >>>> Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.07/ >>>> >>> >>> Looks good, thanks for fixing this. >>> >>> Marcus >>> >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/30 18:38, Marcus Larsson wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> On 2016-06-30 11:31, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi Marcus, >>>>>> >>>>>> Therefore I suggest that we introduce a describe() function in >>>>>>>> LogOutput as part of this change, and move the code currently in >>>>>>>> LogConfiguration::describe to this function, adding the option >>>>>>>> text to it as well. >>>>>>>> >>>>>>> >>>>>> Ah, I understood. >>>>>> If we refactor that in this enhancement, we do not need to make >>>>>> dynamic memory allocation. >>>>>> >>>>>> I uploaded a new webrev. >>>>>> I hope this webrev matches your suggestion :-) >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ >>>>>> >>>>> >>>>> Looks good! Just a nit: Can we keep the printing of the index # in >>>>> LogConfiguration? That would save us from passing it as a parameter >>>>> to describe. (So, print index, call describe, and then print newline.) >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/28 22:21, Yasumasa Suenaga wrote: >>>>>> >>>>>>> Hi Marcus, >>>>>>> >>>>>>> I don't really like that we need to make dynamic allocations here. >>>>>>>> >>>>>>> >>>>>>> Should use resource area? or char array? >>>>>>> If we should use char array, how long should we reserve for buffer? >>>>>>> >>>>>>> >>>>>>> Therefore I suggest that we introduce a describe() function in >>>>>>>> LogOutput as part of this change, and move the code currently in >>>>>>>> LogConfiguration::describe to this function, adding the option >>>>>>>> text to it as well. >>>>>>>> >>>>>>> >>>>>>> I think this is refactoring of LogOutput and LogConfiguration. >>>>>>> Now (after FC date), is this work accepted? >>>>>>> >>>>>>> IMHO, refactoring is another enhancement from this. >>>>>>> If it is needed, I think this enhancement should be started after >>>>>>> refactoring. >>>>>>> >>>>>>> >>>>>>> If refactoring and this enhancement can be merged and be accepted, >>>>>>> I will start to work for it. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/06/28 20:23, Marcus Larsson wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>> I don't really like that we need to make dynamic allocations >>>>>>>> here. I would prefer to have the outputs be responsible for >>>>>>>> describing themselves just like David mentions. The current >>>>>>>> design of LogConfiguration::describe doesn't follow that pattern, >>>>>>>> but I really think it should. Therefore I suggest that we >>>>>>>> introduce a describe() function in LogOutput as part of this >>>>>>>> change, and move the code currently in LogConfiguration::describe >>>>>>>> to this function, adding the option text to it as well. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>> >>>>>>>>> I've requested FC extension for this. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/06/13 13:24, David Holmes wrote: >>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thank you for your comment. >>>>>>>>>>> >>>>>>>>>>> So options are a distinct property of outputs and so should >>>>>>>>>>>> have been >>>>>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I agree to you. >>>>>>>>>>> But I think we need to discuss about it with logging folks. >>>>>>>>>>> >>>>>>>>>>> I uploaded a new webrev. It removes fixed buffer length and >>>>>>>>>>> changes the >>>>>>>>>>> order of output. >>>>>>>>>>> Could you review again? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It's okay to wait and hear what opinions others may have before >>>>>>>>>> changing things based on my comments. :) The fixed buffer may >>>>>>>>>> be okay - as I said I don't know what the potential options >>>>>>>>>> are, so don't know if it is okay or not. >>>>>>>>>> >>>>>>>>>> Using dynamic allocation avoids that but raises other concerns >>>>>>>>>> - like calling vm_exit_on_out_of_memory on failure; or whether >>>>>>>>>> to use malloc or resource area? >>>>>>>>>> >>>>>>>>>> Lets wait for other feedback before going further. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> I think "config_string" is different from "option_string". >>>>>>>>>>>>> >>>>>>>>>>>>> -Xlog format (from -Xlog:help message): >>>>>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>>>>> >>>>>>>>>>>>> config_string: "what" (ex. gc=trace) >>>>>>>>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>>>>>>>> >>>>>>>>>>>>> Currently, LogOutput handles tags and loglevels only as >>>>>>>>>>>>> config_string. >>>>>>>>>>>>> It does not contain output options. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Okay I'm starting to see the bigger picture here. In terms of >>>>>>>>>>>> the >>>>>>>>>>>> overall logging configuration we might have, for example: >>>>>>>>>>>> >>>>>>>>>>>> gc=trace -> stdout >>>>>>>>>>>> runtime=info -> fileA >>>>>>>>>>>> compiler=trace -> fileB >>>>>>>>>>>> >>>>>>>>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>>>>>>>> output. So for each output we set its "configuration" to the >>>>>>>>>>>> associated LHS. >>>>>>>>>>>> >>>>>>>>>>>> So options are a distinct property of outputs and so should >>>>>>>>>>>> have been >>>>>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>>>>> >>>>>>>>>>>> Okay so looking at your v4 I have two comments: >>>>>>>>>>>> >>>>>>>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the >>>>>>>>>>>> possible options >>>>>>>>>>>> are so don't know if 100 is adequate. >>>>>>>>>>>> >>>>>>>>>>>> Second, if the logging syntax is: >>>>>>>>>>>> >>>>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>>>> >>>>>>>>>>>> then shouldn't the configuration be printed in the same >>>>>>>>>>>> order/format? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there some reason the option string could not simply >>>>>>>>>>>>>>>> become >>>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>>> the existing configuration string? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My first proposal keeps option string at LogOutput and its >>>>>>>>>>>>>>> child class >>>>>>>>>>>>>>> (See webrev.01). >>>>>>>>>>>>>>> Marcus commented that option string should be generated >>>>>>>>>>>>>>> from current >>>>>>>>>>>>>>> configuration. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry but I repeat my question - why is the option >>>>>>>>>>>>>> information not >>>>>>>>>>>>>> simply part of the config_string? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>>>>>>>> print_option_string seems the wrong name given that the >>>>>>>>>>>>>>>> base class, >>>>>>>>>>>>>>>> LogOutput, has no notion of having an "option string". It >>>>>>>>>>>>>>>> seems to be >>>>>>>>>>>>>>>> a supposedly generic "print other stuff" function that >>>>>>>>>>>>>>>> only one class >>>>>>>>>>>>>>>> actually needs to implement. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Secondly it inverts the style of the API used for >>>>>>>>>>>>>>>> everything else >>>>>>>>>>>>>>>> - we >>>>>>>>>>>>>>>> have getters for all the other "properties" which are >>>>>>>>>>>>>>>> then printed by >>>>>>>>>>>>>>>> the describe_current_configuration method. But this is >>>>>>>>>>>>>>>> instead a >>>>>>>>>>>>>>>> "print" function where we ask the target to print >>>>>>>>>>>>>>>> itself. Mixing the >>>>>>>>>>>>>>>> two styles seems messy. It probably would have been >>>>>>>>>>>>>>>> better to have >>>>>>>>>>>>>>>> had >>>>>>>>>>>>>>>> a print-style API from the start - then adding the >>>>>>>>>>>>>>>> options would have >>>>>>>>>>>>>>>> been a trivial extension for those output classes with >>>>>>>>>>>>>>>> options. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In addition the change you made to >>>>>>>>>>>>>>>> describe_current_configuration is >>>>>>>>>>>>>>>> not at all general purpose - you wanted a given format >>>>>>>>>>>>>>>> (print between >>>>>>>>>>>>>>>> the config string and the decorators) for this one class >>>>>>>>>>>>>>>> and so you >>>>>>>>>>>>>>>> added the code to support that format. But that format >>>>>>>>>>>>>>>> may not make >>>>>>>>>>>>>>>> sense for other classes that might have "extra stuff" to >>>>>>>>>>>>>>>> print. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is there some reason the option string could not simply >>>>>>>>>>>>>>>> become >>>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>>> the existing configuration string? It seems to me that >>>>>>>>>>>>>>>> for a LogFile >>>>>>>>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PS. The two hpp files would need their copyright years >>>>>>>>>>>>>>>> updated to >>>>>>>>>>>>>>>> "2015, 2016,". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This change is small fix, and it helps us to confirm >>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016/05/10 8:06, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2016/05/04 23:38, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 05/04/2016 04:12 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT >>>>>>>>>>>>>>>>>>>>>> "%s ", >>>>>>>>>>>>>>>>>>>>>> _file_count, byte_size_in_proper_unit(_rotate_size), >>>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size(_rotate_size)); >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, I applied it to new webrev: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Looks OK. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 2016/05/04 22:35, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Looks better. The format for _rotate_size should be >>>>>>>>>>>>>>>>>>>>>> SIZE_FORMAT. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> While we're at it I think it would be good (as I >>>>>>>>>>>>>>>>>>>>>> mentioned) to >>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>> a proper unit for the filesize. Basically changing >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=%lu ", >>>>>>>>>>>>>>>>>>>>>> _file_count, >>>>>>>>>>>>>>>>>>>>>> _rotate_size); >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT >>>>>>>>>>>>>>>>>>>>>> "%s ", >>>>>>>>>>>>>>>>>>>>>> _file_count, byte_size_in_proper_unit(_rotate_size), >>>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size(_rotate_size)); >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I fixed to use _rotate_size and _file_count >>>>>>>>>>>>>>>>>>>>>>> directly to show >>>>>>>>>>>>>>>>>>>>>>> VM.log list jcmd. >>>>>>>>>>>>>>>>>>>>>>> I do not store option string, and I added new >>>>>>>>>>>>>>>>>>>>>>> function to >>>>>>>>>>>>>>>>>>>>>>> print >>>>>>>>>>>>>>>>>>>>>>> option string. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Could you review it again? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 2016/05/04 18:33, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I would prefer to generate the option string from >>>>>>>>>>>>>>>>>>>>>>>> the actual >>>>>>>>>>>>>>>>>>>>>>>> options rather than saving the string from when >>>>>>>>>>>>>>>>>>>>>>>> it was >>>>>>>>>>>>>>>>>>>>>>>> configured. This would also produce/print the >>>>>>>>>>>>>>>>>>>>>>>> options for >>>>>>>>>>>>>>>>>>>>>>>> outputs that are using the defaults (which is not >>>>>>>>>>>>>>>>>>>>>>>> the case >>>>>>>>>>>>>>>>>>>>>>>> now). >>>>>>>>>>>>>>>>>>>>>>>> The filesize option could then use >>>>>>>>>>>>>>>>>>>>>>>> byte_size_in_proper_unit and >>>>>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size to make it easier to read. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Also, get_option_string() should just be called >>>>>>>>>>>>>>>>>>>>>>>> option_string(). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This patch makes to show option string of >>>>>>>>>>>>>>>>>>>>>>>>> LogFileOutput. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I adapted changes to jdk9/hs/hotspot repos. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Please review. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> PING: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I've sent review request for JDK-8153074. >>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> If this patch is merged, user can confirm >>>>>>>>>>>>>>>>>>>>>>>>>>> output option >>>>>>>>>>>>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>>>>>>>>>>>> VM.log jcmd. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Please review and sponsor it. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I want to see output option (filecount, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> filesize) in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VM.log jcmd. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output sample: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #2: gc.log gc=trace, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> filecount=5,filesize=1048576 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> time,level, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>> >>> From volker.simonis at gmail.com Fri Jul 1 07:27:16 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Jul 2016 09:27:16 +0200 Subject: FW: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub In-Reply-To: <5784e9fa319b461fab3c71e624bfb84f@DEWDFE13DE11.global.corp.sap> References: <4ddbcbf03c4046058d911dafae3d177f@DEWDFE13DE11.global.corp.sap> <5732f692217248fdaa9d2d33acb27eea@DEWDFE13DE09.global.corp.sap> <5784e9fa319b461fab3c71e624bfb84f@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, overall the change looks good. Can you please just remove the logic from libo4::removeEscapeMessageFromJoblogByContext() in libo4.cpp. As this is a stub anyway, I think it is perfectly fine to simply return false. There's no need to post a new webrev for that change. Thank you and best regards, Volker On Thu, Jun 30, 2016 at 2:31 PM, Langer, Christoph wrote: > Forgot to include hotspot-runtime mailing list... > > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 30. Juni 2016 11:22 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RE: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > Hi Goetz, > > I added this new structure, too: http://cr.openjdk.java.net/~clanger/webrevs/8160565.2/ > > Thanks > Christoph > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 30. Juni 2016 08:24 >> To: Langer, Christoph ; ppc-aix-port- >> dev at openjdk.java.net >> Subject: RE: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub >> >> Hi Christoph, >> >> thanks for doing these changes, they look good. >> Could you please also include the fixes we did in >> Libperfstat_aix.hpp? >> >> Thanks, >> Goetz. >> >> > -----Original Message----- >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> > bounces at openjdk.java.net] On Behalf Of Langer, Christoph >> > Sent: Mittwoch, 29. Juni 2016 18:28 >> > To: ppc-aix-port-dev at openjdk.java.net >> > Subject: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub >> > >> > Hi, >> > >> > >> > >> > I made a little cleanup in the libo4 wrapper stubs to ease merging. >> > >> > >> > >> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160565.1/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8160565 >> > >> > >> > >> > >> > Thanks >> > >> > Christoph >> > >> > > From christoph.langer at sap.com Fri Jul 1 09:35:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Jul 2016 09:35:38 +0000 Subject: FW: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub In-Reply-To: References: <4ddbcbf03c4046058d911dafae3d177f@DEWDFE13DE11.global.corp.sap> <5732f692217248fdaa9d2d33acb27eea@DEWDFE13DE09.global.corp.sap> <5784e9fa319b461fab3c71e624bfb84f@DEWDFE13DE11.global.corp.sap> Message-ID: Thanks Volker and Goetz. Pushed with your suggestions: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/adc8c84b7cf8 > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 1. Juli 2016 09:27 > To: Langer, Christoph > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: FW: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > Hi Christoph, > > overall the change looks good. > Can you please just remove the logic from > libo4::removeEscapeMessageFromJoblogByContext() in libo4.cpp. As this > is a stub anyway, I think it is perfectly fine to simply return false. > There's no need to post a new webrev for that change. > > Thank you and best regards, > Volker > > > On Thu, Jun 30, 2016 at 2:31 PM, Langer, Christoph > wrote: > > Forgot to include hotspot-runtime mailing list... > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Donnerstag, 30. Juni 2016 11:22 > > To: Lindenmaier, Goetz > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: RE: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > > > Hi Goetz, > > > > I added this new structure, too: > http://cr.openjdk.java.net/~clanger/webrevs/8160565.2/ > > > > Thanks > > Christoph > > > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Donnerstag, 30. Juni 2016 08:24 > >> To: Langer, Christoph ; ppc-aix-port- > >> dev at openjdk.java.net > >> Subject: RE: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > >> > >> Hi Christoph, > >> > >> thanks for doing these changes, they look good. > >> Could you please also include the fixes we did in > >> Libperfstat_aix.hpp? > >> > >> Thanks, > >> Goetz. > >> > >> > -----Original Message----- > >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > >> > bounces at openjdk.java.net] On Behalf Of Langer, Christoph > >> > Sent: Mittwoch, 29. Juni 2016 18:28 > >> > To: ppc-aix-port-dev at openjdk.java.net > >> > Subject: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > >> > > >> > Hi, > >> > > >> > > >> > > >> > I made a little cleanup in the libo4 wrapper stubs to ease merging. > >> > > >> > > >> > > >> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160565.1/ > >> > > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8160565 > >> > > >> > > >> > > >> > > >> > Thanks > >> > > >> > Christoph > >> > > >> > > > From goetz.lindenmaier at sap.com Fri Jul 1 10:14:50 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Jul 2016 10:14:50 +0000 Subject: FW: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub In-Reply-To: References: <4ddbcbf03c4046058d911dafae3d177f@DEWDFE13DE11.global.corp.sap> <5732f692217248fdaa9d2d33acb27eea@DEWDFE13DE09.global.corp.sap> <5784e9fa319b461fab3c71e624bfb84f@DEWDFE13DE11.global.corp.sap> Message-ID: <1b14695b824b48a2b0e715020f2ab676@DEWDFE13DE09.global.corp.sap> Hi Christoph, you sent this for review to hotspot-runtime-dev. So you should have pushed this to jdk9/hs/hotspot. Mailing list and repo are connected, so that people reading the list also find the changes in the corresponding repo. Also, this is necessary to avoid conflicts during merges in the weekly update. hotspot-runtime-dev, hotspot-gc-dev ==> jdk9/hs/hotspot hotspot-compiler-dev ==> jdk9/hs-comp/hotspot Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 1. Juli 2016 11:36 > To: Volker Simonis ; Lindenmaier, Goetz > > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: FW: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > Thanks Volker and Goetz. > > Pushed with your suggestions: > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/adc8c84b7cf8 > > > > -----Original Message----- > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > Sent: Freitag, 1. Juli 2016 09:27 > > To: Langer, Christoph > > Cc: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > > Subject: Re: FW: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > > > Hi Christoph, > > > > overall the change looks good. > > Can you please just remove the logic from > > libo4::removeEscapeMessageFromJoblogByContext() in libo4.cpp. As this > > is a stub anyway, I think it is perfectly fine to simply return false. > > There's no need to post a new webrev for that change. > > > > Thank you and best regards, > > Volker > > > > > > On Thu, Jun 30, 2016 at 2:31 PM, Langer, Christoph > > wrote: > > > Forgot to include hotspot-runtime mailing list... > > > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Donnerstag, 30. Juni 2016 11:22 > > > To: Lindenmaier, Goetz > > > Cc: ppc-aix-port-dev at openjdk.java.net > > > Subject: RE: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > > > > > Hi Goetz, > > > > > > I added this new structure, too: > > http://cr.openjdk.java.net/~clanger/webrevs/8160565.2/ > > > > > > Thanks > > > Christoph > > > > > > > > >> -----Original Message----- > > >> From: Lindenmaier, Goetz > > >> Sent: Donnerstag, 30. Juni 2016 08:24 > > >> To: Langer, Christoph ; ppc-aix-port- > > >> dev at openjdk.java.net > > >> Subject: RE: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > >> > > >> Hi Christoph, > > >> > > >> thanks for doing these changes, they look good. > > >> Could you please also include the fixes we did in > > >> Libperfstat_aix.hpp? > > >> > > >> Thanks, > > >> Goetz. > > >> > > >> > -----Original Message----- > > >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > >> > bounces at openjdk.java.net] On Behalf Of Langer, Christoph > > >> > Sent: Mittwoch, 29. Juni 2016 18:28 > > >> > To: ppc-aix-port-dev at openjdk.java.net > > >> > Subject: RFR(XS): 8160565: AIX port: cleanup of libo4 wrapper stub > > >> > > > >> > Hi, > > >> > > > >> > > > >> > > > >> > I made a little cleanup in the libo4 wrapper stubs to ease merging. > > >> > > > >> > > > >> > > > >> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160565.1/ > > >> > > > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8160565 > > >> > > > >> > > > >> > > > >> > > > >> > Thanks > > >> > > > >> > Christoph > > >> > > > >> > > > > From zoltan.majo at oracle.com Fri Jul 1 11:52:46 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 1 Jul 2016 13:52:46 +0200 Subject: [9] RFR (S): 8160527: Check for final instance field updates can be omitted In-Reply-To: <4571a4af-5f53-fe4d-da98-2fbc73cdb4c1@oracle.com> References: <5773E288.2090104@oracle.com> <734a10e4-20f8-0108-d34c-68278a2d2dfc@oracle.com> <5774EE64.3030904@oracle.com> <4571a4af-5f53-fe4d-da98-2fbc73cdb4c1@oracle.com> Message-ID: <5776598E.8060503@oracle.com> Hi Coleen, thank you for the feedback!Please see details below. On 06/30/2016 10:15 PM, Coleen Phillimore wrote: > > Hi, Looking at this further: > > http://cr.openjdk.java.net/~zmajo/8160527/webrev.01/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html > > > *+ bool final_instance_update = info.field_holder()->major_version() > >= 53 &&* > *+ info.has_initialized_final_update() &&* > *+ (bytecode == Bytecodes::_putfield || bytecode == > Bytecodes::_nofast_putfield);* > *+ * > *+ * > > I think you can test info.access_flags().is_final() and not use the > new has_initialized_final_update() flag. > > If the current_class of the function with the putfield is not the same > as the class owning the field, an error would be thrown in > linkResolver.cpp and the bytecode would never be marked as resolved in > the constant pool of the current_class (only the class owning the > field). If the field is_final, it'll only be initialized in the > function so no point marking it resolved in the cpCache of the > resolved_class anyway. I agree,but based on your second suggestion (below), it seems we don't need the variable 'final_instance_update' anymore. Please see below. > > It seems like this is_put part of this 'if' statement: > > if (!uninitialized_static) { > get_code = ((is_static) ? Bytecodes::_getstatic : > Bytecodes::_getfield); > if (is_put || !info.access_flags().is_final()) { > put_code = ((is_static) ? Bytecodes::_putstatic : > Bytecodes::_putfield); > } > } > > Should be moved up to: > > // We need to delay resolving put instructions on final fields > // until we actually invoke one. This is required so we throw > // exceptions at the correct place. If we do not resolve completely > // in the current pass, leaving the put_code set to zero will > // cause the next put instruction to reresolve. > Bytecodes::Code put_code = (Bytecodes::Code)0; > if (is_put && !info.access_flags().is_final()) { > put_code = ((is_static) ? Bytecodes::_putstatic : > Bytecodes::_putfield); > } > > Where it'll match the comment. Yes, that is a good idea. But in the original code 'put_code' is set only if !uninitialized_static is true. 595 if (!uninitialized_static) { 596 get_code = ((is_static) ? Bytecodes::_getstatic : Bytecodes::_getfield); 597 if (is_put || !info.access_flags().is_final()) { 598 put_code = ((is_static) ? Bytecodes::_putstatic : Bytecodes::_putfield); 599 } 600 } Therefore, the conditionyou've suggested if (is_put && !info.access_flags().is_final()) { should include !uninitialized_static as well if (is_put && !info.access_flags().is_final() && !uninitialized_static) { The comment // We also need to delay resolving getstatic instructions until the // class is intitialized. This is required so that access to the static should be updated as well to // We also need to delay resolving getstatic and *putstatic* instructions until the // class is intitialized. This is required so that access to the static as we delay putstatic instructions as well. I restructured the code (incl. comments) accordingly. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8160527/webrev.02/ JPRT testing passes. Thank you! Best regards, Zoltan > > Coleen > > On 6/30/16 3:31 PM, Coleen Phillimore wrote: >> >> Zoltan, >> >> On 6/30/16 6:03 AM, Zolt?n Maj? wrote: >>> Hi Coleen, >>> >>> >>> thank you for the feedback and for the review! Please see below. >>> >>> On 06/29/2016 11:01 PM, Coleen Phillimore wrote: >>>> >>>> Zoltan, >>>> >>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html >>>> >>>> >>>> Yes, this matches the general strategy. You don't have to have >>>> this line >>>> >>>> *+ (bytecode == Bytecodes::_putfield || bytecode == >>>> Bytecodes::_nofast_putfield);* >>>> >>>> >>>> Because the test below is: >>>> >>>> *!if (_(_is_put_&& !final_instance_update)_|| >>>> !info.access_flags().is_final()) {* >>> >>> I think we need the condition >>> >>> (bytecode == Bytecodes::_putfield || bytecode == >>> Bytecodes::_nofast_putfield); >>> >>> for 'final_instance_update'. The reason is that we need to detect >>> invalid updates only to *instance* fields but not to *static* >>> fields; the condition 'is_put' includes Bytecodes::_putstatic as well. >>> >>> bool is_put = (bytecode == Bytecodes::_putfield || bytecode == >>> Bytecodes::_nofast_putfield || >>> --> bytecode == Bytecodes::_putstatic); >>> >>> The reason do not need to include putstatic is that the current >>> delaying mechanism [1] [2] works fine for static final fields (but >>> it is insufficient for instance final fields). >> >> ok. >> >>> >>> To check that invalid updates to static fields are properly >>> detected, I've added a new test, TestPutStatic.jasm. The test is >>> analogous to the TestPutField.jasm test that you've seen in the >>> previous webrev (webrev.00); the VM passes the test already in its >>> current state (without the change). >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.01/ >> >> This looks good. >>> >>> I re-tested with JPRT, all tests (incl. the newly added ones) pass. >>> >>>> >>>> >>>> Otherwise, looks fine. I'm sorry I didn't realize this in the >>>> initial code review. >>> >>> I did not realize either that this problem existed -- good that John >>> has pointed it out. >>> >> >> Thanks, >> Coleen >> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> [1] >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l579 >>> [2] >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l586 >>> >>>> >>>> Coleen >>>> >>>> >>>> On 6/29/16 11:00 AM, Zolt?n Maj? wrote: >>>>> Hi, >>>>> >>>>> >>>>> please review the patch for 8160527. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8160527 >>>>> >>>>> Problem: 8157181 added a check that verifies that final instance >>>>> fields can be updated only by object initializer methods (as >>>>> required by JVMS >=7) [1]. >>>>> >>>>> Unfortunately, the newly added check can be circumvented due to >>>>> constant pool caching: If the instance field update is executed in >>>>> an method first, the instruction updating the field is >>>>> cached in the constant pool cache. Subsequent updates use the >>>>> constant pool cache (and do not call into the VM where the check >>>>> is executed). As a result, any method can update a final instance >>>>> field if that field was first updated in an instance initializer >>>>> (the method must be declared in the same class as the field, though). >>>>> >>>>> John's comment in the bug description provides more detailed >>>>> information on how the above can happen. >>>>> >>>>> >>>>> Solution: Do not cache putfield instructions to final instance >>>>> fields if the verifier has detected that the field is updated in >>>>> other methods than (i.e., has_initialized_field_update() >>>>> returns true for the field). Avoiding caching results in the field >>>>> access being re-resolved until the offending access is attempted; >>>>> then an exception is thrown. Avoiding caching must be done very >>>>> infrequently, as offending code is rare (e.g., such code cannot be >>>>> produced by javac). >>>>> >>>>> I've also corrected a small mistake in the fix for 8157181 (the >>>>> class name is printed in the error message instead of the method's >>>>> name). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/ >>>>> >>>>> Testing: >>>>> - JPRT (testset hotspot, incl. newly added test); >>>>> - verified that the newly added test triggers the problem with an >>>>> unmodified VM. >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c558d46c1af2#l11.76 >>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Jul 1 12:39:51 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 1 Jul 2016 08:39:51 -0400 Subject: [9] RFR (S): 8160527: Check for final instance field updates can be omitted In-Reply-To: <5776598E.8060503@oracle.com> References: <5773E288.2090104@oracle.com> <734a10e4-20f8-0108-d34c-68278a2d2dfc@oracle.com> <5774EE64.3030904@oracle.com> <4571a4af-5f53-fe4d-da98-2fbc73cdb4c1@oracle.com> <5776598E.8060503@oracle.com> Message-ID: <6dc7f90f-1bd6-7caa-88be-2b7b49ff4489@oracle.com> On 7/1/16 7:52 AM, Zolt?n Maj? wrote: > Hi Coleen, > > > thank you for the feedback!Please see details below. > > On 06/30/2016 10:15 PM, Coleen Phillimore wrote: >> >> Hi, Looking at this further: >> >> http://cr.openjdk.java.net/~zmajo/8160527/webrev.01/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html >> >> >> *+ bool final_instance_update = info.field_holder()->major_version() >> >= 53 &&* >> *+ info.has_initialized_final_update() &&* >> *+ (bytecode == Bytecodes::_putfield || bytecode == >> Bytecodes::_nofast_putfield);* >> *+ * >> *+ * >> >> I think you can test info.access_flags().is_final() and not use the >> new has_initialized_final_update() flag. >> >> If the current_class of the function with the putfield is not the >> same as the class owning the field, an error would be thrown in >> linkResolver.cpp and the bytecode would never be marked as resolved >> in the constant pool of the current_class (only the class owning the >> field). If the field is_final, it'll only be initialized in the >> function so no point marking it resolved in the cpCache of the >> resolved_class anyway. > > I agree,but based on your second suggestion (below), it seems we don't > need the variable 'final_instance_update' anymore. Please see below. > >> >> It seems like this is_put part of this 'if' statement: >> >> if (!uninitialized_static) { >> get_code = ((is_static) ? Bytecodes::_getstatic : >> Bytecodes::_getfield); >> if (is_put || !info.access_flags().is_final()) { >> put_code = ((is_static) ? Bytecodes::_putstatic : >> Bytecodes::_putfield); >> } >> } >> >> Should be moved up to: >> >> // We need to delay resolving put instructions on final fields >> // until we actually invoke one. This is required so we throw >> // exceptions at the correct place. If we do not resolve completely >> // in the current pass, leaving the put_code set to zero will >> // cause the next put instruction to reresolve. >> Bytecodes::Code put_code = (Bytecodes::Code)0; >> if (is_put && !info.access_flags().is_final()) { >> put_code = ((is_static) ? Bytecodes::_putstatic : >> Bytecodes::_putfield); >> } >> >> Where it'll match the comment. > > Yes, that is a good idea. > > But in the original code 'put_code' is set only if > !uninitialized_static is true. > > 595 if (!uninitialized_static) { > 596 get_code = ((is_static) ? Bytecodes::_getstatic : > Bytecodes::_getfield); > 597 if (is_put || !info.access_flags().is_final()) { > 598 put_code = ((is_static) ? Bytecodes::_putstatic : > Bytecodes::_putfield); > 599 } > 600 } > > > Therefore, the conditionyou've suggested > > if (is_put && !info.access_flags().is_final()) { > > should include !uninitialized_static as well > > if (is_put && !info.access_flags().is_final() && > !uninitialized_static) { Okay, I see it now. uninitialized_static is to delay resolution for the nonfinal fields. > > The comment > > // We also need to delay resolving getstatic instructions until the > // class is intitialized. This is required so that access to the static > should be updated as well to > > // We also need to delay resolving getstatic and *putstatic* > instructions until the > // class is intitialized. This is required so that access to the static > > as we delay putstatic instructions as well. > > I restructured the code (incl. comments) accordingly. Here is the > updated webrev: > http://cr.openjdk.java.net/~zmajo/8160527/webrev.02/ Yes, this looks very good. It's much clearer because it was confusing with all these conditions. > > JPRT testing passes. There's a test for delaying resolution for non-final fields somewhere. Did you find that? I think it's in the compiler jtreg directories. Thanks, Coleen > > Thank you! > > Best regards, > > > Zoltan > > > >> >> Coleen >> >> On 6/30/16 3:31 PM, Coleen Phillimore wrote: >>> >>> Zoltan, >>> >>> On 6/30/16 6:03 AM, Zolt?n Maj? wrote: >>>> Hi Coleen, >>>> >>>> >>>> thank you for the feedback and for the review! Please see below. >>>> >>>> On 06/29/2016 11:01 PM, Coleen Phillimore wrote: >>>>> >>>>> Zoltan, >>>>> >>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html >>>>> >>>>> >>>>> Yes, this matches the general strategy. You don't have to have >>>>> this line >>>>> >>>>> *+ (bytecode == Bytecodes::_putfield || bytecode == >>>>> Bytecodes::_nofast_putfield);* >>>>> >>>>> >>>>> Because the test below is: >>>>> >>>>> *!if (_(_is_put_&& !final_instance_update)_|| >>>>> !info.access_flags().is_final()) {* >>>> >>>> I think we need the condition >>>> >>>> (bytecode == Bytecodes::_putfield || bytecode == >>>> Bytecodes::_nofast_putfield); >>>> >>>> for 'final_instance_update'. The reason is that we need to detect >>>> invalid updates only to *instance* fields but not to *static* >>>> fields; the condition 'is_put' includes Bytecodes::_putstatic as well. >>>> >>>> bool is_put = (bytecode == Bytecodes::_putfield || bytecode == >>>> Bytecodes::_nofast_putfield || >>>> --> bytecode == Bytecodes::_putstatic); >>>> >>>> The reason do not need to include putstatic is that the current >>>> delaying mechanism [1] [2] works fine for static final fields (but >>>> it is insufficient for instance final fields). >>> >>> ok. >>> >>>> >>>> To check that invalid updates to static fields are properly >>>> detected, I've added a new test, TestPutStatic.jasm. The test is >>>> analogous to the TestPutField.jasm test that you've seen in the >>>> previous webrev (webrev.00); the VM passes the test already in its >>>> current state (without the change). >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.01/ >>> >>> This looks good. >>>> >>>> I re-tested with JPRT, all tests (incl. the newly added ones) pass. >>>> >>>>> >>>>> >>>>> Otherwise, looks fine. I'm sorry I didn't realize this in the >>>>> initial code review. >>>> >>>> I did not realize either that this problem existed -- good that >>>> John has pointed it out. >>>> >>> >>> Thanks, >>> Coleen >>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l579 >>>> [2] >>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l586 >>>> >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 6/29/16 11:00 AM, Zolt?n Maj? wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the patch for 8160527. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8160527 >>>>>> >>>>>> Problem: 8157181 added a check that verifies that final instance >>>>>> fields can be updated only by object initializer methods (as >>>>>> required by JVMS >=7) [1]. >>>>>> >>>>>> Unfortunately, the newly added check can be circumvented due to >>>>>> constant pool caching: If the instance field update is executed >>>>>> in an method first, the instruction updating the field is >>>>>> cached in the constant pool cache. Subsequent updates use the >>>>>> constant pool cache (and do not call into the VM where the check >>>>>> is executed). As a result, any method can update a final instance >>>>>> field if that field was first updated in an instance initializer >>>>>> (the method must be declared in the same class as the field, >>>>>> though). >>>>>> >>>>>> John's comment in the bug description provides more detailed >>>>>> information on how the above can happen. >>>>>> >>>>>> >>>>>> Solution: Do not cache putfield instructions to final instance >>>>>> fields if the verifier has detected that the field is updated in >>>>>> other methods than (i.e., has_initialized_field_update() >>>>>> returns true for the field). Avoiding caching results in the >>>>>> field access being re-resolved until the offending access is >>>>>> attempted; then an exception is thrown. Avoiding caching must be >>>>>> done very infrequently, as offending code is rare (e.g., such >>>>>> code cannot be produced by javac). >>>>>> >>>>>> I've also corrected a small mistake in the fix for 8157181 (the >>>>>> class name is printed in the error message instead of the >>>>>> method's name). >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - JPRT (testset hotspot, incl. newly added test); >>>>>> - verified that the newly added test triggers the problem with an >>>>>> unmodified VM. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c558d46c1af2#l11.76 >>>>>> >>>>>> >>>>> >>>> >>> >> > From zoltan.majo at oracle.com Fri Jul 1 13:33:29 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 1 Jul 2016 15:33:29 +0200 Subject: [9] RFR (S): 8160527: Check for final instance field updates can be omitted In-Reply-To: <6dc7f90f-1bd6-7caa-88be-2b7b49ff4489@oracle.com> References: <5773E288.2090104@oracle.com> <734a10e4-20f8-0108-d34c-68278a2d2dfc@oracle.com> <5774EE64.3030904@oracle.com> <4571a4af-5f53-fe4d-da98-2fbc73cdb4c1@oracle.com> <5776598E.8060503@oracle.com> <6dc7f90f-1bd6-7caa-88be-2b7b49ff4489@oracle.com> Message-ID: <57767129.1080603@oracle.com> Hi Coleen, thank you for the feedback! Please see below. On 07/01/2016 02:39 PM, Coleen Phillimore wrote: > [...] >> >> I restructured the code (incl. comments) accordingly. Here is the >> updated webrev: >> http://cr.openjdk.java.net/~zmajo/8160527/webrev.02/ > > Yes, this looks very good. It's much clearer because it was > confusing with all these conditions. Thank you! > > >> >> JPRT testing passes. > > There's a test for delaying resolution for non-final fields > somewhere. Did you find that? I think it's in the compiler jtreg > directories. I have not found that test, unfortunately. If you point me to the test, I'd be glad to run it. Alternatively, I can run all hotspot tests on all supported platforms with -Xmixed and -Xcomp. That testbase has a good potential for triggering problems. Thank you! Best regards, Zoltan > > Thanks, > Coleen >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >> >>> >>> Coleen >>> >>> On 6/30/16 3:31 PM, Coleen Phillimore wrote: >>>> >>>> Zoltan, >>>> >>>> On 6/30/16 6:03 AM, Zolt?n Maj? wrote: >>>>> Hi Coleen, >>>>> >>>>> >>>>> thank you for the feedback and for the review! Please see below. >>>>> >>>>> On 06/29/2016 11:01 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Zoltan, >>>>>> >>>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html >>>>>> >>>>>> >>>>>> Yes, this matches the general strategy. You don't have to have >>>>>> this line >>>>>> >>>>>> *+ (bytecode == Bytecodes::_putfield || bytecode == >>>>>> Bytecodes::_nofast_putfield);* >>>>>> >>>>>> >>>>>> Because the test below is: >>>>>> >>>>>> *!if (_(_is_put_&& !final_instance_update)_|| >>>>>> !info.access_flags().is_final()) {* >>>>> >>>>> I think we need the condition >>>>> >>>>> (bytecode == Bytecodes::_putfield || bytecode == >>>>> Bytecodes::_nofast_putfield); >>>>> >>>>> for 'final_instance_update'. The reason is that we need to detect >>>>> invalid updates only to *instance* fields but not to *static* >>>>> fields; the condition 'is_put' includes Bytecodes::_putstatic as >>>>> well. >>>>> >>>>> bool is_put = (bytecode == Bytecodes::_putfield || bytecode == >>>>> Bytecodes::_nofast_putfield || >>>>> --> bytecode == Bytecodes::_putstatic); >>>>> >>>>> The reason do not need to include putstatic is that the current >>>>> delaying mechanism [1] [2] works fine for static final fields (but >>>>> it is insufficient for instance final fields). >>>> >>>> ok. >>>> >>>>> >>>>> To check that invalid updates to static fields are properly >>>>> detected, I've added a new test, TestPutStatic.jasm. The test is >>>>> analogous to the TestPutField.jasm test that you've seen in the >>>>> previous webrev (webrev.00); the VM passes the test already in its >>>>> current state (without the change). >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.01/ >>>> >>>> This looks good. >>>>> >>>>> I re-tested with JPRT, all tests (incl. the newly added ones) pass. >>>>> >>>>>> >>>>>> >>>>>> Otherwise, looks fine. I'm sorry I didn't realize this in the >>>>>> initial code review. >>>>> >>>>> I did not realize either that this problem existed -- good that >>>>> John has pointed it out. >>>>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l579 >>>>> [2] >>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l586 >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 6/29/16 11:00 AM, Zolt?n Maj? wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> please review the patch for 8160527. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160527 >>>>>>> >>>>>>> Problem: 8157181 added a check that verifies that final instance >>>>>>> fields can be updated only by object initializer methods (as >>>>>>> required by JVMS >=7) [1]. >>>>>>> >>>>>>> Unfortunately, the newly added check can be circumvented due to >>>>>>> constant pool caching: If the instance field update is executed >>>>>>> in an method first, the instruction updating the field is >>>>>>> cached in the constant pool cache. Subsequent updates use the >>>>>>> constant pool cache (and do not call into the VM where the check >>>>>>> is executed). As a result, any method can update a final >>>>>>> instance field if that field was first updated in an instance >>>>>>> initializer (the method must be declared in the same class as >>>>>>> the field, though). >>>>>>> >>>>>>> John's comment in the bug description provides more detailed >>>>>>> information on how the above can happen. >>>>>>> >>>>>>> >>>>>>> Solution: Do not cache putfield instructions to final instance >>>>>>> fields if the verifier has detected that the field is updated in >>>>>>> other methods than (i.e., has_initialized_field_update() >>>>>>> returns true for the field). Avoiding caching results in the >>>>>>> field access being re-resolved until the offending access is >>>>>>> attempted; then an exception is thrown. Avoiding caching must be >>>>>>> done very infrequently, as offending code is rare (e.g., such >>>>>>> code cannot be produced by javac). >>>>>>> >>>>>>> I've also corrected a small mistake in the fix for 8157181 (the >>>>>>> class name is printed in the error message instead of the >>>>>>> method's name). >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/ >>>>>>> >>>>>>> Testing: >>>>>>> - JPRT (testset hotspot, incl. newly added test); >>>>>>> - verified that the newly added test triggers the problem with >>>>>>> an unmodified VM. >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> [1] >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c558d46c1af2#l11.76 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From derek.white at oracle.com Fri Jul 1 13:50:51 2016 From: derek.white at oracle.com (Derek White) Date: Fri, 1 Jul 2016 09:50:51 -0400 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <8abab997-31ec-ea9c-3e1b-5e114a14750a@oracle.com> References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> <8abab997-31ec-ea9c-3e1b-5e114a14750a@oracle.com> Message-ID: <80542bc8-86ed-5065-05b3-fb08bd2aacfb@oracle.com> Thanks David! - Derek On 6/30/16 10:09 PM, David Holmes wrote: > On 1/07/2016 7:15 AM, Derek White wrote: >> New webrev goes back to using java_lang_Class::set_oop_size(new_cls, >> size); >> >> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ > > Much neater/simpler :) Thanks. > > Aside: I had no idea we could do printf style strings in asserts! When > did we get that? :) > > Thanks, > David > ----- > >> jprt run in progress. Built w/ and w/o PCH. >> >> On 6/30/16 7:56 AM, Derek White wrote: >>> On 6/30/16 12:28 AM, David Holmes wrote: >>>> Hi Derek, >>>> >>>> Understand the fix in principle. >>>> >>>> But I don't understand why you got rid of >>>> java_lang_Class::set_oop_size, and instead exposed >>>> java_lang_Class::oop_size_offset(), then had >>>> InstanceMirrorKlass::allocate_instance pass the offset to >>>> CollectedHeap::class_allocate, which passes it to >>>> CollectedHeap::post_allocation_setup_class - that seems rather >>>> convoluted. Can CollectedHeap::post_allocation_setup_class not call >>>> java_lang_Class::set_oop_size directly? >>> >>> Short answer is I didn't think so. collectedHeap.inline.hpp has a very >>> small include set, and I was concerned about circular dependencies. >>> Another approach would be to push ::set_oop_size() over to >>> instanceKlassMirror.hpp, and see if the includes seem saner that way. >>> I'll try some alternatives... >> >> OK, doing the simple and obvious thing worked out after all. Thanks >> David! >> >> - Derek From yasuenag at gmail.com Fri Jul 1 14:16:08 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Jul 2016 23:16:08 +0900 Subject: Status of building problem with GCC 6 Message-ID: Hi all, I want to share task list for building OpenJDK with GCC 6. * jdk: - JDK-8160294: reviewing * hotspot Subtasks of JDK-8160310: - JDK-8160353: reviewing (includes patch for JDK-8156980) - JDK-8160354: reviewing (a part of fix depends on JDK-8156980) - JDK-8160356: waiting to push - JDK-8160357: might be discarded if JDK-8156980 will be resolved. - JDK-8160361: waiting to push - JDK-8160363: might be discarded if JDK-8156980 will be resolved. For HotSpot, I think JDK-8156980 should be fixed at first. I've proposed changes as below: ----------- diff -r ba08710f3b6c make/lib/CompileJvm.gmk --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 @@ -187,6 +187,11 @@ JVM_OPTIMIZATION ?= HIGHEST_JVM +JVM_CXXFLAGS := $(JVM_CFLAGS) +ifeq ($(TOOLCHAIN_TYPE), gcc) + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse +endif + ################################################################################ # Now set up the actual compilation of the main hotspot native library @@ -202,6 +207,7 @@ CFLAGS := $(JVM_CFLAGS), \ CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ + CXXFLAGS := $(JVM_CXXFLAGS), \ vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ empty-body format logical-op-parentheses parentheses \ ----------- I guess GCC 6 (or later) will be provided from several Linux Distros in near future. In fact, Fedora 24 already provides it. I'm sure this work helps many developers who use Linux. Thanks, Yasumasa From zoltan.majo at oracle.com Mon Jul 4 08:56:19 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 4 Jul 2016 10:56:19 +0200 Subject: [9] RFR (S): 8160527: Check for final instance field updates can be omitted In-Reply-To: <57767129.1080603@oracle.com> References: <5773E288.2090104@oracle.com> <734a10e4-20f8-0108-d34c-68278a2d2dfc@oracle.com> <5774EE64.3030904@oracle.com> <4571a4af-5f53-fe4d-da98-2fbc73cdb4c1@oracle.com> <5776598E.8060503@oracle.com> <6dc7f90f-1bd6-7caa-88be-2b7b49ff4489@oracle.com> <57767129.1080603@oracle.com> Message-ID: <577A24B3.1080203@oracle.com> Hi Coleen, On 07/01/2016 03:33 PM, Zolt?n Maj? wrote: > [...] > >> >> >>> >>> JPRT testing passes. >> >> There's a test for delaying resolution for non-final fields >> somewhere. Did you find that? I think it's in the compiler jtreg >> directories. > > I have not found that test, unfortunately. If you point me to the > test, I'd be glad to run it. > > Alternatively, I can run all hotspot tests on all supported platforms > with -Xmixed and -Xcomp. That testbase has a good potential for > triggering problems. I've run all hotspot tests on all supported platforms with -Xmixed and -Xcomp. The change does not trigger any failures. I plan to push the latest webrev (webrev.02) to hs on Wednesday, July 6 (unless, of course, there are objections). Thank you! Best regards, Zoltan > > Thank you! > > Best regards, > > > Zoltan > > >> >> Thanks, >> Coleen >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>> >>>> Coleen >>>> >>>> On 6/30/16 3:31 PM, Coleen Phillimore wrote: >>>>> >>>>> Zoltan, >>>>> >>>>> On 6/30/16 6:03 AM, Zolt?n Maj? wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> >>>>>> thank you for the feedback and for the review! Please see below. >>>>>> >>>>>> On 06/29/2016 11:01 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Zoltan, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> Yes, this matches the general strategy. You don't have to have >>>>>>> this line >>>>>>> >>>>>>> *+ (bytecode == Bytecodes::_putfield || bytecode == >>>>>>> Bytecodes::_nofast_putfield);* >>>>>>> >>>>>>> >>>>>>> Because the test below is: >>>>>>> >>>>>>> *!if (_(_is_put_&& !final_instance_update)_|| >>>>>>> !info.access_flags().is_final()) {* >>>>>> >>>>>> I think we need the condition >>>>>> >>>>>> (bytecode == Bytecodes::_putfield || bytecode == >>>>>> Bytecodes::_nofast_putfield); >>>>>> >>>>>> for 'final_instance_update'. The reason is that we need to detect >>>>>> invalid updates only to *instance* fields but not to *static* >>>>>> fields; the condition 'is_put' includes Bytecodes::_putstatic as >>>>>> well. >>>>>> >>>>>> bool is_put = (bytecode == Bytecodes::_putfield || bytecode >>>>>> == Bytecodes::_nofast_putfield || >>>>>> --> bytecode == Bytecodes::_putstatic); >>>>>> >>>>>> The reason do not need to include putstatic is that the current >>>>>> delaying mechanism [1] [2] works fine for static final fields >>>>>> (but it is insufficient for instance final fields). >>>>> >>>>> ok. >>>>> >>>>>> >>>>>> To check that invalid updates to static fields are properly >>>>>> detected, I've added a new test, TestPutStatic.jasm. The test is >>>>>> analogous to the TestPutField.jasm test that you've seen in the >>>>>> previous webrev (webrev.00); the VM passes the test already in >>>>>> its current state (without the change). >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.01/ >>>>> >>>>> This looks good. >>>>>> >>>>>> I re-tested with JPRT, all tests (incl. the newly added ones) pass. >>>>>> >>>>>>> >>>>>>> >>>>>>> Otherwise, looks fine. I'm sorry I didn't realize this in the >>>>>>> initial code review. >>>>>> >>>>>> I did not realize either that this problem existed -- good that >>>>>> John has pointed it out. >>>>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l579 >>>>>> [2] >>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2af3fb9f244f/src/share/vm/interpreter/interpreterRuntime.cpp#l586 >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 6/29/16 11:00 AM, Zolt?n Maj? wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> please review the patch for 8160527. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160527 >>>>>>>> >>>>>>>> Problem: 8157181 added a check that verifies that final >>>>>>>> instance fields can be updated only by object initializer >>>>>>>> methods (as required by JVMS >=7) [1]. >>>>>>>> >>>>>>>> Unfortunately, the newly added check can be circumvented due to >>>>>>>> constant pool caching: If the instance field update is executed >>>>>>>> in an method first, the instruction updating the field >>>>>>>> is cached in the constant pool cache. Subsequent updates use >>>>>>>> the constant pool cache (and do not call into the VM where the >>>>>>>> check is executed). As a result, any method can update a final >>>>>>>> instance field if that field was first updated in an instance >>>>>>>> initializer (the method must be declared in the same class as >>>>>>>> the field, though). >>>>>>>> >>>>>>>> John's comment in the bug description provides more detailed >>>>>>>> information on how the above can happen. >>>>>>>> >>>>>>>> >>>>>>>> Solution: Do not cache putfield instructions to final instance >>>>>>>> fields if the verifier has detected that the field is updated >>>>>>>> in other methods than (i.e., >>>>>>>> has_initialized_field_update() returns true for the field). >>>>>>>> Avoiding caching results in the field access being re-resolved >>>>>>>> until the offending access is attempted; then an exception is >>>>>>>> thrown. Avoiding caching must be done very infrequently, as >>>>>>>> offending code is rare (e.g., such code cannot be produced by >>>>>>>> javac). >>>>>>>> >>>>>>>> I've also corrected a small mistake in the fix for 8157181 (the >>>>>>>> class name is printed in the error message instead of the >>>>>>>> method's name). >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~zmajo/8160527/webrev.00/ >>>>>>>> >>>>>>>> Testing: >>>>>>>> - JPRT (testset hotspot, incl. newly added test); >>>>>>>> - verified that the newly added test triggers the problem with >>>>>>>> an unmodified VM. >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c558d46c1af2#l11.76 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.schatzl at oracle.com Mon Jul 4 12:18:48 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 04 Jul 2016 14:18:48 +0200 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: <1467634728.8604.7.camel@oracle.com> Hi Derek, On Thu, 2016-06-30 at 17:15 -0400, Derek White wrote: > New webrev goes back to using java_lang_Class::set_oop_size(new_cls, > size); > > http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ > > jprt run in progress. Built w/ and w/o PCH. - the assert in java_lang_Class::oop_size() could be a bit improved, maybe use the same message as for oopDesc::size_given_class() for the same check, maybe the same in java_lang_class::set_oop_size() - I am not sure if the comment above CollectedHeap::class_allocate() makes any sense at that location. This is far from where it is actually set and seems to be only a random comment. I do not need a re-review for these fix-ups. Looks good. Thanks, ? Thomas From kim.barrett at oracle.com Tue Jul 5 17:15:22 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Jul 2016 13:15:22 -0400 Subject: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: <37654526-1275-4848-829D-96A508F7D4D8@oracle.com> > On Jun 30, 2016, at 5:15 PM, Derek White wrote: > > New webrev goes back to using java_lang_Class::set_oop_size(new_cls, size); > > http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ Looks good. From derek.white at oracle.com Tue Jul 5 18:42:39 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 5 Jul 2016 14:42:39 -0400 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1467634728.8604.7.camel@oracle.com> References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> <1467634728.8604.7.camel@oracle.com> Message-ID: <76c7d3bf-8ee3-a22b-e264-537db99b2aa9@oracle.com> OK, Thanks Thomas! - Derek On 7/4/16 8:18 AM, Thomas Schatzl wrote: > Hi Derek, > > On Thu, 2016-06-30 at 17:15 -0400, Derek White wrote: >> New webrev goes back to using java_lang_Class::set_oop_size(new_cls, >> size); >> >> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ >> >> jprt run in progress. Built w/ and w/o PCH. > - the assert in java_lang_Class::oop_size() could be a bit improved, > maybe use the same message as for oopDesc::size_given_class() for the > same check, maybe the same in java_lang_class::set_oop_size() > > - I am not sure if the comment above CollectedHeap::class_allocate() > makes any sense at that location. This is far from where it is actually > set and seems to be only a random comment. > > I do not need a re-review for these fix-ups. > > Looks good. > > Thanks, > Thomas > > From derek.white at oracle.com Tue Jul 5 18:42:55 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 5 Jul 2016 14:42:55 -0400 Subject: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <37654526-1275-4848-829D-96A508F7D4D8@oracle.com> References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> <37654526-1275-4848-829D-96A508F7D4D8@oracle.com> Message-ID: Thanks Kim! - Derek On 7/5/16 1:15 PM, Kim Barrett wrote: >> On Jun 30, 2016, at 5:15 PM, Derek White wrote: >> >> New webrev goes back to using java_lang_Class::set_oop_size(new_cls, size); >> >> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/ > Looks good. > From vladimir.kozlov at oracle.com Tue Jul 5 22:47:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jul 2016 15:47:30 -0700 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> Message-ID: CC to runtime too since it has changes in Interpreter and affects our closed code. Hi Goetz, Please, set "Fix Version". And if it is JDK 9 you need FC Extension Request since you converted it to Enhancement: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html Someone from Oracle have to sponsor it and do related closed code changes and testing. Thanks, Vladimir On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: > Hi, > > could someone please have a look at this issue? I recap the description > below, and I also updated the webrev which would no more apply to > hs-comp: > > c1_LIR.hpp defines a row of functions guarded by platform > defines. This is bad style and hinders new platform ports. > (I'm working on S390 aka Z :)) > > This change removes the majority of these defines. It introduces > common headers, and moves implementations to c1_LIR_.cpp files. > > It guards single_softfp() and double_softfp() by __SOFTFP__. > This is not used in any openJdk platform. I can not test this > on the closed platforms ARM32 and PPC32. > > It removes the guard around the LIR_Address constructor. There > is no point in guarding this code, verify() assures by > assertions that it can not be misused. I also introduce a new > constructor that leaves out the scale argument and introduce > some usages on X86. > > This change also moves verify() to the new platform files. In the > header, LIR_ADDRESS_PD_VERIFY was used to guard usage > of pd_verify(). Neither of these are used in openJdk. If this define > is used in the closed ports pd_verify() must be renamed to verify(). > > The code that was previously guarded by ARM, ARM32 or PPC32 is > moved to a properly guarded section in c1_LIR.cpp. Actually, > it should be moved to according new files c1_LIR_.cpp in > the closed ports. But this way the change should basically > work for the closed ports. > > I added fnoreg on x86 to note down the code similarly on all > platforms. > > I cleaned up a flag with a limited range on PPC_32. > > generate_stack_overflow_check() in templateInterpreterGenerator.hpp > is defined with different parameters for the platforms. I added default > parameters noreg so that the signature is the same for all platforms. > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8160245 > http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ > > I built and tested this on linuxx86_64, solaris_sparc and > the ppc platforms. > > Best regards, > Goetz. > > From coleen.phillimore at oracle.com Tue Jul 5 23:23:40 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jul 2016 19:23:40 -0400 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> Message-ID: Why is there a third register parameter to generate_stack_overflow_check() that is unused on all the platforms? I would almost rather have one version with no arguments overloaded with one with two, than three default parameters. It seems dangerous. thanks, Coleen On 7/5/16 6:47 PM, Vladimir Kozlov wrote: > CC to runtime too since it has changes in Interpreter and affects our > closed code. > > Hi Goetz, > > Please, set "Fix Version". > > And if it is JDK 9 you need FC Extension Request since you converted > it to Enhancement: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > > Someone from Oracle have to sponsor it and do related closed code > changes and testing. > > Thanks, > Vladimir > > On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> could someone please have a look at this issue? I recap the description >> below, and I also updated the webrev which would no more apply to >> hs-comp: >> >> c1_LIR.hpp defines a row of functions guarded by platform >> defines. This is bad style and hinders new platform ports. >> (I'm working on S390 aka Z :)) >> >> This change removes the majority of these defines. It introduces >> common headers, and moves implementations to c1_LIR_.cpp files. >> >> It guards single_softfp() and double_softfp() by __SOFTFP__. >> This is not used in any openJdk platform. I can not test this >> on the closed platforms ARM32 and PPC32. >> >> It removes the guard around the LIR_Address constructor. There >> is no point in guarding this code, verify() assures by >> assertions that it can not be misused. I also introduce a new >> constructor that leaves out the scale argument and introduce >> some usages on X86. >> >> This change also moves verify() to the new platform files. In the >> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >> of pd_verify(). Neither of these are used in openJdk. If this define >> is used in the closed ports pd_verify() must be renamed to verify(). >> >> The code that was previously guarded by ARM, ARM32 or PPC32 is >> moved to a properly guarded section in c1_LIR.cpp. Actually, >> it should be moved to according new files c1_LIR_.cpp in >> the closed ports. But this way the change should basically >> work for the closed ports. >> >> I added fnoreg on x86 to note down the code similarly on all >> platforms. >> >> I cleaned up a flag with a limited range on PPC_32. >> >> generate_stack_overflow_check() in templateInterpreterGenerator.hpp >> is defined with different parameters for the platforms. I added default >> parameters noreg so that the signature is the same for all platforms. >> >> Please review this change. I please need a sponsor. >> https://bugs.openjdk.java.net/browse/JDK-8160245 >> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ >> >> I built and tested this on linuxx86_64, solaris_sparc and >> the ppc platforms. >> >> Best regards, >> Goetz. >> >> From dmitry.samersoff at oracle.com Wed Jul 6 08:56:54 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Jul 2016 11:56:54 +0300 Subject: RFR(S), URG: JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 In-Reply-To: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> References: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> Message-ID: Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ -Dmitry -------- Forwarded Message -------- Subject: RFR(S): JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 Date: Wed, 29 Jun 2016 19:12:25 +0300 From: Dmitry Samersoff To: serviceability-dev at openjdk.java.net Everybody, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ The problem: If you run the test from symlinked location user.dir and the output of jps -l may not match to the value returned by File.getAbsolutePath() for the same jar file. Solution: Skip the test if user.dir doesn't match File.getAbsolutePath() -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ivan.gerasimov at oracle.com Wed Jul 6 16:57:04 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 6 Jul 2016 19:57:04 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out Message-ID: Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and registers itself, 2) Thread B wants to call exit(), takes its turn and raises the flag `process_exiting`, 3) Thread A continues, and gets captured in the loop at 4020, in SuspendThread(GetCurrentThread()), 4) Now, the thread B will have to wait for all the registered threads, including the thread A, which will never wake up. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ With kind regards, Ivan From daniel.daugherty at oracle.com Wed Jul 6 17:55:47 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 11:55:47 -0600 Subject: RFR(S), URG: JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 In-Reply-To: References: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> Message-ID: <7f4974be-38f8-4b92-7755-94d2156fc877@oracle.com> On 7/6/16 2:56 AM, Dmitry Samersoff wrote: > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ test/sun/tools/jps/JpsBase.java L64 if (!fullProcessName.startsWith(userDir)) { L65 System.err.printf("Test skipped. user.dir '%s' doesn't match '%s'\n", userDir, fullProcessName); Since you're using startsWith(), the error message should be changed like this: cur: "doesn't match" new: "is not a prefix of" L98: // Skip the test if user.dir doesn't match current path Please change "doesn't match" -> "is not a prefix of the" L99: // It's possible if the test run from symlinked dir or windows alias drive Typo: "test run" -> "test is run" test/sun/tools/jps/TestJpsJar.java No comments. Thumbs up modulo the comment corrections. No need to see a new webrev for those fixes. Please update copyright years before pushing. Dan > > -Dmitry > > -------- Forwarded Message -------- > Subject: RFR(S): JDK-8159925 sun/tools/jps/TestJpsJar.java still fails > after fix for JDK-8153278 > Date: Wed, 29 Jun 2016 19:12:25 +0300 > From: Dmitry Samersoff > To: serviceability-dev at openjdk.java.net > > > Everybody, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ > > The problem: > > If you run the test from symlinked location user.dir and the output of > jps -l may not match to the value returned by File.getAbsolutePath() for > the same jar file. > > Solution: > > Skip the test if user.dir doesn't match File.getAbsolutePath() > > -Dmitry > > From goetz.lindenmaier at sap.com Wed Jul 6 19:02:13 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Jul 2016 19:02:13 +0000 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> Message-ID: <921d2766f4d349e29b1fe83f2bb385c0@DEWDFE13DE09.global.corp.sap> Hi Coleen, You're right, I only need two args. That's wrong because I edited it before 8159335 was merged to hs-comp which removed an argument. I'll fix that. For the overloaded functions, do you want me to add an implementation with ShouldNotReachHere() for the unused versions? And isn't that basically the same as having unused parameters? Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Wednesday, July 06, 2016 1:24 AM > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > c1_LIR.hpp. > > > Why is there a third register parameter to > generate_stack_overflow_check() that is unused on all the platforms? > > I would almost rather have one version with no arguments overloaded with > one with two, than three default parameters. It seems dangerous. > > thanks, > Coleen > > On 7/5/16 6:47 PM, Vladimir Kozlov wrote: > > CC to runtime too since it has changes in Interpreter and affects our > > closed code. > > > > Hi Goetz, > > > > Please, set "Fix Version". > > > > And if it is JDK 9 you need FC Extension Request since you converted > > it to Enhancement: > > > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > > > > Someone from Oracle have to sponsor it and do related closed code > > changes and testing. > > > > Thanks, > > Vladimir > > > > On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: > >> Hi, > >> > >> could someone please have a look at this issue? I recap the description > >> below, and I also updated the webrev which would no more apply to > >> hs-comp: > >> > >> c1_LIR.hpp defines a row of functions guarded by platform > >> defines. This is bad style and hinders new platform ports. > >> (I'm working on S390 aka Z :)) > >> > >> This change removes the majority of these defines. It introduces > >> common headers, and moves implementations to c1_LIR_.cpp files. > >> > >> It guards single_softfp() and double_softfp() by __SOFTFP__. > >> This is not used in any openJdk platform. I can not test this > >> on the closed platforms ARM32 and PPC32. > >> > >> It removes the guard around the LIR_Address constructor. There > >> is no point in guarding this code, verify() assures by > >> assertions that it can not be misused. I also introduce a new > >> constructor that leaves out the scale argument and introduce > >> some usages on X86. > >> > >> This change also moves verify() to the new platform files. In the > >> header, LIR_ADDRESS_PD_VERIFY was used to guard usage > >> of pd_verify(). Neither of these are used in openJdk. If this define > >> is used in the closed ports pd_verify() must be renamed to verify(). > >> > >> The code that was previously guarded by ARM, ARM32 or PPC32 is > >> moved to a properly guarded section in c1_LIR.cpp. Actually, > >> it should be moved to according new files c1_LIR_.cpp in > >> the closed ports. But this way the change should basically > >> work for the closed ports. > >> > >> I added fnoreg on x86 to note down the code similarly on all > >> platforms. > >> > >> I cleaned up a flag with a limited range on PPC_32. > >> > >> generate_stack_overflow_check() in templateInterpreterGenerator.hpp > >> is defined with different parameters for the platforms. I added default > >> parameters noreg so that the signature is the same for all platforms. > >> > >> Please review this change. I please need a sponsor. > >> https://bugs.openjdk.java.net/browse/JDK-8160245 > >> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ > >> > >> I built and tested this on linuxx86_64, solaris_sparc and > >> the ppc platforms. > >> > >> Best regards, > >> Goetz. > >> > >> From coleen.phillimore at oracle.com Wed Jul 6 19:30:40 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Jul 2016 15:30:40 -0400 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <921d2766f4d349e29b1fe83f2bb385c0@DEWDFE13DE09.global.corp.sap> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <921d2766f4d349e29b1fe83f2bb385c0@DEWDFE13DE09.global.corp.sap> Message-ID: <7519a465-858d-f4be-dab2-c81e860d5e9b@oracle.com> On 7/6/16 3:02 PM, Lindenmaier, Goetz wrote: > Hi Coleen, > > You're right, I only need two args. That's wrong because I edited > it before 8159335 was merged to hs-comp which removed an > argument. I'll fix that. > > For the overloaded functions, do you want me to add > an implementation with ShouldNotReachHere() for the > unused versions? And isn't that basically the same as having > unused parameters? I don't think it's necessary to have a ShouldNotReachHere for the unused versions. If you call the one with no parameters on a platform with the two parameter implementation, you'll get an undefined reference at linktime, which is better than a crash. With the noreg default parameter versions, you could make the mistake of not passing any registers or the wrong number of registers, and I guess the result would be a crash at runtime but that can be hard to understand why it happened. So I would prefer both declarations without default arguments, and each platform code calls the right version and doesn't call the other. Coleen > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- >> bounces at openjdk.java.net] On Behalf Of Coleen Phillimore >> Sent: Wednesday, July 06, 2016 1:24 AM >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >> c1_LIR.hpp. >> >> >> Why is there a third register parameter to >> generate_stack_overflow_check() that is unused on all the platforms? >> >> I would almost rather have one version with no arguments overloaded with >> one with two, than three default parameters. It seems dangerous. >> >> thanks, >> Coleen >> >> On 7/5/16 6:47 PM, Vladimir Kozlov wrote: >>> CC to runtime too since it has changes in Interpreter and affects our >>> closed code. >>> >>> Hi Goetz, >>> >>> Please, set "Fix Version". >>> >>> And if it is JDK 9 you need FC Extension Request since you converted >>> it to Enhancement: >>> >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html >>> >>> Someone from Oracle have to sponsor it and do related closed code >>> changes and testing. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> could someone please have a look at this issue? I recap the description >>>> below, and I also updated the webrev which would no more apply to >>>> hs-comp: >>>> >>>> c1_LIR.hpp defines a row of functions guarded by platform >>>> defines. This is bad style and hinders new platform ports. >>>> (I'm working on S390 aka Z :)) >>>> >>>> This change removes the majority of these defines. It introduces >>>> common headers, and moves implementations to c1_LIR_.cpp files. >>>> >>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>> This is not used in any openJdk platform. I can not test this >>>> on the closed platforms ARM32 and PPC32. >>>> >>>> It removes the guard around the LIR_Address constructor. There >>>> is no point in guarding this code, verify() assures by >>>> assertions that it can not be misused. I also introduce a new >>>> constructor that leaves out the scale argument and introduce >>>> some usages on X86. >>>> >>>> This change also moves verify() to the new platform files. In the >>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>> >>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>> it should be moved to according new files c1_LIR_.cpp in >>>> the closed ports. But this way the change should basically >>>> work for the closed ports. >>>> >>>> I added fnoreg on x86 to note down the code similarly on all >>>> platforms. >>>> >>>> I cleaned up a flag with a limited range on PPC_32. >>>> >>>> generate_stack_overflow_check() in templateInterpreterGenerator.hpp >>>> is defined with different parameters for the platforms. I added default >>>> parameters noreg so that the signature is the same for all platforms. >>>> >>>> Please review this change. I please need a sponsor. >>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ >>>> >>>> I built and tested this on linuxx86_64, solaris_sparc and >>>> the ppc platforms. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> From serguei.spitsyn at oracle.com Wed Jul 6 19:35:32 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Jul 2016 12:35:32 -0700 Subject: RFR(S), URG: JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 In-Reply-To: References: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> Message-ID: <577D5D84.7010809@oracle.com> Hi Dmitry, Should the fix cover other test flags: m, v or V ? Otherwise, it looks good, modulo the comments from Dan. Thanks, Serguei On 7/6/16 01:56, Dmitry Samersoff wrote: > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ > > -Dmitry > > -------- Forwarded Message -------- > Subject: RFR(S): JDK-8159925 sun/tools/jps/TestJpsJar.java still fails > after fix for JDK-8153278 > Date: Wed, 29 Jun 2016 19:12:25 +0300 > From: Dmitry Samersoff > To: serviceability-dev at openjdk.java.net > > > Everybody, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ > > The problem: > > If you run the test from symlinked location user.dir and the output of > jps -l may not match to the value returned by File.getAbsolutePath() for > the same jar file. > > Solution: > > Skip the test if user.dir doesn't match File.getAbsolutePath() > > -Dmitry > > From dmitry.samersoff at oracle.com Wed Jul 6 20:12:35 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Jul 2016 23:12:35 +0300 Subject: RFR(S), URG: JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 In-Reply-To: <577D5D84.7010809@oracle.com> References: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> <577D5D84.7010809@oracle.com> Message-ID: <69571fad-e8d9-7ef3-d446-3f80b5ffc5e0@oracle.com> Serguei, > Should the fix cover other test flags: m, v or V ? > Otherwise, it looks good, modulo the comments from Dan. Probably yes, but it's out of scope of this changes. Thank you for the review! -Dmitry On 2016-07-06 22:35, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > Should the fix cover other test flags: m, v or V ? > Otherwise, it looks good, modulo the comments from Dan. > > Thanks, > Serguei > > > On 7/6/16 01:56, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ >> >> -Dmitry >> >> -------- Forwarded Message -------- >> Subject: RFR(S): JDK-8159925 sun/tools/jps/TestJpsJar.java still fails >> after fix for JDK-8153278 >> Date: Wed, 29 Jun 2016 19:12:25 +0300 >> From: Dmitry Samersoff >> To: serviceability-dev at openjdk.java.net >> >> >> Everybody, >> >> Please review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ >> >> The problem: >> >> If you run the test from symlinked location user.dir and the output of >> jps -l may not match to the value returned by File.getAbsolutePath() for >> the same jar file. >> >> Solution: >> >> Skip the test if user.dir doesn't match File.getAbsolutePath() >> >> -Dmitry >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Jul 6 20:13:22 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Jul 2016 23:13:22 +0300 Subject: RFR(S), URG: JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 In-Reply-To: <7f4974be-38f8-4b92-7755-94d2156fc877@oracle.com> References: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> <7f4974be-38f8-4b92-7755-94d2156fc877@oracle.com> Message-ID: Dan, Thank you! Will fix comments. -Dmitry On 2016-07-06 20:55, Daniel D. Daugherty wrote: > On 7/6/16 2:56 AM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ > > test/sun/tools/jps/JpsBase.java > L64 if (!fullProcessName.startsWith(userDir)) { > L65 System.err.printf("Test skipped. user.dir '%s' > doesn't match '%s'\n", userDir, fullProcessName); > Since you're using startsWith(), the error message should > be changed like this: > > cur: "doesn't match" > new: "is not a prefix of" > > L98: // Skip the test if user.dir doesn't match > current path > Please change "doesn't match" -> "is not a prefix of the" > > L99: // It's possible if the test run from > symlinked dir or windows alias drive > Typo: "test run" -> "test is run" > > test/sun/tools/jps/TestJpsJar.java > No comments. > > Thumbs up modulo the comment corrections. > No need to see a new webrev for those fixes. > > Please update copyright years before pushing. > > Dan > > >> >> -Dmitry >> >> -------- Forwarded Message -------- >> Subject: RFR(S): JDK-8159925 sun/tools/jps/TestJpsJar.java still fails >> after fix for JDK-8153278 >> Date: Wed, 29 Jun 2016 19:12:25 +0300 >> From: Dmitry Samersoff >> To: serviceability-dev at openjdk.java.net >> >> >> Everybody, >> >> Please review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ >> >> The problem: >> >> If you run the test from symlinked location user.dir and the output of >> jps -l may not match to the value returned by File.getAbsolutePath() for >> the same jar file. >> >> Solution: >> >> Skip the test if user.dir doesn't match File.getAbsolutePath() >> >> -Dmitry >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Wed Jul 6 21:21:11 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 15:21:11 -0600 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: References: Message-ID: <96448437-61c1-f4a2-922b-f4a9477ad460@oracle.com> On 7/6/16 10:57 AM, Ivan Gerasimov wrote: > Hello! > > When fixing JDK-8069048 a potential race was overlooked: > 1) Thread A wants to call _endthreadex() and registers itself, > 2) Thread B wants to call exit(), takes its turn and raises the flag > `process_exiting`, > 3) Thread A continues, and gets captured in the loop at 4020, in > SuspendThread(GetCurrentThread()), > 4) Now, the thread B will have to wait for all the registered threads, > including the thread A, which will never wake up. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 > WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ src/os/windows/vm/os_windows.cpp Just to make sure the race is clear (in my mind at least): Thread A - executes if-block at L3913-3968; in particular it registers itself on L3957 - executes if-block at L4017-4027; in the old code, the thread would block for ever in L4022-4026; in the new code, the thread will only block if it did not register itself. Thread B: - executes if-block at L3906-3910 and succeeds in setting the process_exiting flag - executes if-block at L3969-4012; in particular Thread B calls WaitForMultipleObjects() on L3994; in the old code, WaitForMultipleObjects() times out because Thread A is blocked. L3963: registered_itself = true; L3964: } L3965: L3966: // The current exiting thread has stored its handle in the array, and now L3967: // should leave the critical section before calling _endthreadex(). The existing comment on L3966-3967 belongs after L3963 and before L3964, i.e., at the end of the else-block. If you agree with moving the comment on L3966-3967, then consider this next request: L3959: warning("DuplicateHandle failed (%u) in %s: %d\n", L3960: GetLastError(), __FILE__, __LINE__); Please consider adding the following comment after the warning: // We can't register this thread (no more handles) so this thread // may be racing with a thread that is calling exit(). If the thread // that is calling exit() has managed to set the process_exiting // flag, then this thread will be caught in the SuspendThread() // infinite loop below which closes that race. A small timing // window remains before the process_exiting flag is set, but it // is only exposed when we are out of handles. L4021: // don't let the current thread proceed to exit() or _endthreadex() Clarify comment: 'current thread' -> 'current unregistered thread' Very nice and very quick job in finding this race! Thumbs up on what you have since my comments are only related to moving/adding comments. Dan > > With kind regards, > Ivan > From ivan.gerasimov at oracle.com Wed Jul 6 23:09:56 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 7 Jul 2016 02:09:56 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <96448437-61c1-f4a2-922b-f4a9477ad460@oracle.com> References: <96448437-61c1-f4a2-922b-f4a9477ad460@oracle.com> Message-ID: Thanks Daniel! I'll rearrange comments as you suggest. With kind regards, Ivan On 07.07.2016 0:21, Daniel D. Daugherty wrote: > On 7/6/16 10:57 AM, Ivan Gerasimov wrote: >> Hello! >> >> When fixing JDK-8069048 a potential race was overlooked: >> 1) Thread A wants to call _endthreadex() and registers itself, >> 2) Thread B wants to call exit(), takes its turn and raises the flag >> `process_exiting`, >> 3) Thread A continues, and gets captured in the loop at 4020, in >> SuspendThread(GetCurrentThread()), >> 4) Now, the thread B will have to wait for all the registered >> threads, including the thread A, which will never wake up. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ > > src/os/windows/vm/os_windows.cpp > Just to make sure the race is clear (in my mind at least): > > Thread A > - executes if-block at L3913-3968; in particular it > registers itself on L3957 > - executes if-block at L4017-4027; in the old code, > the thread would block for ever in L4022-4026; in > the new code, the thread will only block if it did > not register itself. > > Thread B: > - executes if-block at L3906-3910 and succeeds in > setting the process_exiting flag > - executes if-block at L3969-4012; in particular > Thread B calls WaitForMultipleObjects() on L3994; > in the old code, WaitForMultipleObjects() times > out because Thread A is blocked. > > L3963: registered_itself = true; > L3964: } > L3965: > L3966: // The current exiting thread has stored its handle > in the array, and now > L3967: // should leave the critical section before calling > _endthreadex(). > The existing comment on L3966-3967 belongs after L3963 and before > L3964, i.e., at the end of the else-block. > > If you agree with moving the comment on L3966-3967, then > consider this next request: > > L3959: warning("DuplicateHandle failed (%u) in %s: %d\n", > L3960: GetLastError(), __FILE__, __LINE__); > > Please consider adding the following comment after the warning: > > // We can't register this thread (no more handles) so this thread > // may be racing with a thread that is calling exit(). If the > thread > // that is calling exit() has managed to set the process_exiting > // flag, then this thread will be caught in the SuspendThread() > // infinite loop below which closes that race. A small timing > // window remains before the process_exiting flag is set, but it > // is only exposed when we are out of handles. > > L4021: // don't let the current thread proceed to exit() or > _endthreadex() > Clarify comment: 'current thread' > -> 'current unregistered thread' > > Very nice and very quick job in finding this race! > > Thumbs up on what you have since my comments are only related > to moving/adding comments. > > Dan > > >> >> With kind regards, >> Ivan >> > > From goetz.lindenmaier at sap.com Thu Jul 7 06:59:50 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Jul 2016 06:59:50 +0000 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <7519a465-858d-f4be-dab2-c81e860d5e9b@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <921d2766f4d349e29b1fe83f2bb385c0@DEWDFE13DE09.global.corp.sap> <7519a465-858d-f4be-dab2-c81e860d5e9b@oracle.com> Message-ID: Hi Coleen, I edited the change according to your comments and made a new webrev: http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.03/ Best regards, Goetz. > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Mittwoch, 6. Juli 2016 21:31 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > c1_LIR.hpp. > > > > On 7/6/16 3:02 PM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > You're right, I only need two args. That's wrong because I edited > > it before 8159335 was merged to hs-comp which removed an > > argument. I'll fix that. > > > > For the overloaded functions, do you want me to add > > an implementation with ShouldNotReachHere() for the > > unused versions? And isn't that basically the same as having > > unused parameters? > > I don't think it's necessary to have a ShouldNotReachHere for the unused > versions. If you call the one with no parameters on a platform with > the two parameter implementation, you'll get an undefined reference at > linktime, which is better than a crash. > > With the noreg default parameter versions, you could make the mistake of > not passing any registers or the wrong number of registers, and I guess > the result would be a crash at runtime but that can be hard to > understand why it happened. > > So I would prefer both declarations without default arguments, and each > platform code calls the right version and doesn't call the other. > > Coleen > > > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > >> bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > >> Sent: Wednesday, July 06, 2016 1:24 AM > >> To: hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > >> c1_LIR.hpp. > >> > >> > >> Why is there a third register parameter to > >> generate_stack_overflow_check() that is unused on all the platforms? > >> > >> I would almost rather have one version with no arguments overloaded > with > >> one with two, than three default parameters. It seems dangerous. > >> > >> thanks, > >> Coleen > >> > >> On 7/5/16 6:47 PM, Vladimir Kozlov wrote: > >>> CC to runtime too since it has changes in Interpreter and affects our > >>> closed code. > >>> > >>> Hi Goetz, > >>> > >>> Please, set "Fix Version". > >>> > >>> And if it is JDK 9 you need FC Extension Request since you converted > >>> it to Enhancement: > >>> > >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > June/004443.html > >>> > >>> Someone from Oracle have to sponsor it and do related closed code > >>> changes and testing. > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> could someone please have a look at this issue? I recap the description > >>>> below, and I also updated the webrev which would no more apply to > >>>> hs-comp: > >>>> > >>>> c1_LIR.hpp defines a row of functions guarded by platform > >>>> defines. This is bad style and hinders new platform ports. > >>>> (I'm working on S390 aka Z :)) > >>>> > >>>> This change removes the majority of these defines. It introduces > >>>> common headers, and moves implementations to c1_LIR_.cpp > files. > >>>> > >>>> It guards single_softfp() and double_softfp() by __SOFTFP__. > >>>> This is not used in any openJdk platform. I can not test this > >>>> on the closed platforms ARM32 and PPC32. > >>>> > >>>> It removes the guard around the LIR_Address constructor. There > >>>> is no point in guarding this code, verify() assures by > >>>> assertions that it can not be misused. I also introduce a new > >>>> constructor that leaves out the scale argument and introduce > >>>> some usages on X86. > >>>> > >>>> This change also moves verify() to the new platform files. In the > >>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage > >>>> of pd_verify(). Neither of these are used in openJdk. If this define > >>>> is used in the closed ports pd_verify() must be renamed to verify(). > >>>> > >>>> The code that was previously guarded by ARM, ARM32 or PPC32 is > >>>> moved to a properly guarded section in c1_LIR.cpp. Actually, > >>>> it should be moved to according new files c1_LIR_.cpp in > >>>> the closed ports. But this way the change should basically > >>>> work for the closed ports. > >>>> > >>>> I added fnoreg on x86 to note down the code similarly on all > >>>> platforms. > >>>> > >>>> I cleaned up a flag with a limited range on PPC_32. > >>>> > >>>> generate_stack_overflow_check() in > templateInterpreterGenerator.hpp > >>>> is defined with different parameters for the platforms. I added default > >>>> parameters noreg so that the signature is the same for all platforms. > >>>> > >>>> Please review this change. I please need a sponsor. > >>>> https://bugs.openjdk.java.net/browse/JDK-8160245 > >>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- > simplifyC1/webrev.02/ > >>>> > >>>> I built and tested this on linuxx86_64, solaris_sparc and > >>>> the ppc platforms. > >>>> > >>>> Best regards, > >>>> Goetz. > >>>> > >>>> From coleen.phillimore at oracle.com Thu Jul 7 11:47:23 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Jul 2016 07:47:23 -0400 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <921d2766f4d349e29b1fe83f2bb385c0@DEWDFE13DE09.global.corp.sap> <7519a465-858d-f4be-dab2-c81e860d5e9b@oracle.com> Message-ID: Hi Goetz, The interpreter changes look good. Since the more substantive changes are in c1, I think you want a reviewer/sponsor from the compiler area. thanks, Coleen On 7/7/16 2:59 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > I edited the change according to your comments and made a new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.03/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Mittwoch, 6. Juli 2016 21:31 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >> c1_LIR.hpp. >> >> >> >> On 7/6/16 3:02 PM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> You're right, I only need two args. That's wrong because I edited >>> it before 8159335 was merged to hs-comp which removed an >>> argument. I'll fix that. >>> >>> For the overloaded functions, do you want me to add >>> an implementation with ShouldNotReachHere() for the >>> unused versions? And isn't that basically the same as having >>> unused parameters? >> I don't think it's necessary to have a ShouldNotReachHere for the unused >> versions. If you call the one with no parameters on a platform with >> the two parameter implementation, you'll get an undefined reference at >> linktime, which is better than a crash. >> >> With the noreg default parameter versions, you could make the mistake of >> not passing any registers or the wrong number of registers, and I guess >> the result would be a crash at runtime but that can be hard to >> understand why it happened. >> >> So I would prefer both declarations without default arguments, and each >> platform code calls the right version and doesn't call the other. >> >> Coleen >> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- >>>> bounces at openjdk.java.net] On Behalf Of Coleen Phillimore >>>> Sent: Wednesday, July 06, 2016 1:24 AM >>>> To: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>>> c1_LIR.hpp. >>>> >>>> >>>> Why is there a third register parameter to >>>> generate_stack_overflow_check() that is unused on all the platforms? >>>> >>>> I would almost rather have one version with no arguments overloaded >> with >>>> one with two, than three default parameters. It seems dangerous. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 7/5/16 6:47 PM, Vladimir Kozlov wrote: >>>>> CC to runtime too since it has changes in Interpreter and affects our >>>>> closed code. >>>>> >>>>> Hi Goetz, >>>>> >>>>> Please, set "Fix Version". >>>>> >>>>> And if it is JDK 9 you need FC Extension Request since you converted >>>>> it to Enhancement: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >> June/004443.html >>>>> Someone from Oracle have to sponsor it and do related closed code >>>>> changes and testing. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> could someone please have a look at this issue? I recap the description >>>>>> below, and I also updated the webrev which would no more apply to >>>>>> hs-comp: >>>>>> >>>>>> c1_LIR.hpp defines a row of functions guarded by platform >>>>>> defines. This is bad style and hinders new platform ports. >>>>>> (I'm working on S390 aka Z :)) >>>>>> >>>>>> This change removes the majority of these defines. It introduces >>>>>> common headers, and moves implementations to c1_LIR_.cpp >> files. >>>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>>>> This is not used in any openJdk platform. I can not test this >>>>>> on the closed platforms ARM32 and PPC32. >>>>>> >>>>>> It removes the guard around the LIR_Address constructor. There >>>>>> is no point in guarding this code, verify() assures by >>>>>> assertions that it can not be misused. I also introduce a new >>>>>> constructor that leaves out the scale argument and introduce >>>>>> some usages on X86. >>>>>> >>>>>> This change also moves verify() to the new platform files. In the >>>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>>>> >>>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>>>> it should be moved to according new files c1_LIR_.cpp in >>>>>> the closed ports. But this way the change should basically >>>>>> work for the closed ports. >>>>>> >>>>>> I added fnoreg on x86 to note down the code similarly on all >>>>>> platforms. >>>>>> >>>>>> I cleaned up a flag with a limited range on PPC_32. >>>>>> >>>>>> generate_stack_overflow_check() in >> templateInterpreterGenerator.hpp >>>>>> is defined with different parameters for the platforms. I added default >>>>>> parameters noreg so that the signature is the same for all platforms. >>>>>> >>>>>> Please review this change. I please need a sponsor. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- >> simplifyC1/webrev.02/ >>>>>> I built and tested this on linuxx86_64, solaris_sparc and >>>>>> the ppc platforms. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> From jiangli.zhou at Oracle.COM Fri Jul 8 01:08:26 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Thu, 7 Jul 2016 18:08:26 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true Message-ID: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: JDK-8141341 With -Xshare:on If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. With -Xshare:auto The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. Thanks, Jiangli From ioi.lam at oracle.com Fri Jul 8 01:56:54 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 07 Jul 2016 18:56:54 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> Message-ID: <577F0866.2050606@oracle.com> (Adding serviceability-dev at openjdk.java.net) Hi Jiangli, I think the two blocks of if (RequireSharedSpaces) { tty->print_cr("An error has occurred while loading shared class."); tty->print_cr("Tool agent requires sharing to be disabled."); vm_exit(1); } should be removed. If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like jvmtiError JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { ... if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { + if (RequireSharedSpaces && !universe::is_bootstraping()) { + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); + return JVMTI_ERROR_ILLEGAL_ARGUMENT; + } record_class_file_load_hook_enabled(); } ... } Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: > Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. > > webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ > bug: JDK-8141341 > > With -Xshare:on > If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. > > With -Xshare:auto > The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. > > The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. > > Thanks, > Jiangli > > From karen.kinnear at oracle.com Fri Jul 8 14:55:27 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Jul 2016 10:55:27 -0400 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <577F0866.2050606@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> Message-ID: <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> Jiangli, Thank you so much for picking up this bug fix, I very much appreciate that. I agree with not quitting the vm on agent attach. I actually think we also want the agent attach to succeed - see below. > On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: > > (Adding serviceability-dev at openjdk.java.net) > > Hi Jiangli, > > I think the two blocks of > > if (RequireSharedSpaces) { > tty->print_cr("An error has occurred while loading shared class."); > tty->print_cr("Tool agent requires sharing to be disabled."); > vm_exit(1); > } > > should be removed. I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, but no forcing of using the shared spaces if there is an agent. > > If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. > > If the agent is attached later, after the VM has started, I think we should not quit the VM. Totally agree - we should not quit the VM. > Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like > > jvmtiError > JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { > > ... > if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { > + if (RequireSharedSpaces && !universe::is_bootstraping()) { > + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); > + return JVMTI_ERROR_ILLEGAL_ARGUMENT; > + } > record_class_file_load_hook_enabled(); > } > ? > } > I was expecting the vm to continue running, letting the agent attach (customers really want to use these). Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. > > Thanks > - Ioi Jiangli: Minor code review comments: metaspace.cpp line 3181: CFHL-> CFLH metaspace.cpp: I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. I think it would make sense to do a bit more of that - e.g. cds_address appears to only be use locally, so it also could be inside the #if INCLUDE_CDS. Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? thanks, Karen > > > > On 7/7/16 6:08 PM, Jiangli Zhou wrote: >> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >> bug: JDK-8141341 >> >> With -Xshare:on >> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >> >> With -Xshare:auto >> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >> >> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >> >> Thanks, >> Jiangli >> >> > From dmitry.samersoff at oracle.com Fri Jul 8 16:53:16 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 8 Jul 2016 19:53:16 +0300 Subject: RFR(XS): URG: Quarantine jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java in JDK9-dev Message-ID: <293e3462-aaeb-6597-decb-e8d46dd8fc46@oracle.com> Everybody, Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8161074/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Fri Jul 8 16:58:28 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Jul 2016 10:58:28 -0600 Subject: RFR(XS): URG: Quarantine jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java in JDK9-dev In-Reply-To: <293e3462-aaeb-6597-decb-e8d46dd8fc46@oracle.com> References: <293e3462-aaeb-6597-decb-e8d46dd8fc46@oracle.com> Message-ID: On 7/8/16 10:53 AM, Dmitry Samersoff wrote: > Everybody, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8161074/webrev.01/ test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java No comments. Thumbs up. Dan > > -Dmitry > From george.triantafillou at oracle.com Fri Jul 8 17:01:57 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 8 Jul 2016 13:01:57 -0400 Subject: RFR(XS): URG: Quarantine jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java in JDK9-dev In-Reply-To: References: <293e3462-aaeb-6597-decb-e8d46dd8fc46@oracle.com> Message-ID: <285724a9-902a-e0f0-100c-7471ef2c967f@oracle.com> +1 -George On 7/8/2016 12:58 PM, Daniel D. Daugherty wrote: > On 7/8/16 10:53 AM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8161074/webrev.01/ > > test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java > > No comments. > > Thumbs up. > > Dan > > >> >> -Dmitry >> > From jiangli.zhou at oracle.com Fri Jul 8 18:13:22 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 11:13:22 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <577F0866.2050606@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> Message-ID: Hi Ioi, Thanks for the comments. > On Jul 7, 2016, at 6:56 PM, Ioi Lam wrote: > > (Adding serviceability-dev at openjdk.java.net) > > Hi Jiangli, > > I think the two blocks of > > if (RequireSharedSpaces) { > tty->print_cr("An error has occurred while loading shared class."); > tty->print_cr("Tool agent requires sharing to be disabled."); > vm_exit(1); > } > > should be removed. > > If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp I noticed in some cases the JvmtiExport::should_post_class_file_load_hook is not enabled very early during VM initialization, but rather at a later time for agent specified in the command line. When agent has SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_CLASS_FILE_LOAD_HOOK?), the enabling of the JvmtiExport::should_post_class_file_load_hook is done early and can be handled by the check in meatspace.cpp. In other case, the capability is enabled later, which is after the mapping of the shared spaces and initializing of the preloaded classes. Here is the stack trace of the later case: #0 JvmtiExport::set_should_post_class_file_load_hook(bool) () #1 0x00007ffff617fe3e in JvmtiEventControllerPrivate::recompute_enabled() () #2 0x00007ffff6180607 in JvmtiEventControllerPrivate::set_event_callbacks(JvmtiEnvBase*, jvmtiEventCallbacks const*, int) () #3 0x00007ffff6181557 in JvmtiEventController::set_event_callbacks(JvmtiEnvBase*, jvmtiEventCallbacks const*, int) () #4 0x00007ffff6169ca2 in JvmtiEnv::SetEventCallbacks(jvmtiEventCallbacks const*, int) () #5 0x00007ffff61206d1 in jvmti_SetEventCallbacks () #6 0x00007ffff47bed27 in setLivePhaseEventHandlers () #7 0x00007ffff47be47f in processJavaStart () #8 0x00007ffff47bd0fe in eventHandlerVMInit () #9 0x00007ffff6183727 in JvmtiExport::post_vm_initialized() () #10 0x00007ffff65d560c in Threads::create_vm(JavaVMInitArgs*, bool*) () #11 0x00007ffff607fc6f in JNI_CreateJavaVM_inner(JavaVM_**, void**, void*) () #12 0x00007ffff607fffd in JNI_CreateJavaVM () #13 0x00007ffff7798c9e in InitializeJVM () #14 0x00007ffff77960ba in JavaMain () #15 0x00007ffff79ade9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #16 0x00007ffff72c34bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #17 0x0000000000000000 in ?? () If we don?t want to abort the VM running -Xshare:on with dynamically attached agent, maybe we can do the JvmtiExport::should_post_class_file_load_hook check after JvmtiExport::post_vm_initialized(). Then we can remove the 'if (RequireSharedSpaces) {? blocks from the load_shared_class(). Thanks, Jiangli > > If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like > > jvmtiError > JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { > > ... > if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { > + if (RequireSharedSpaces && !universe::is_bootstraping()) { > + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); > + return JVMTI_ERROR_ILLEGAL_ARGUMENT; > + } > record_class_file_load_hook_enabled(); > } > ... > } > > > Thanks > - Ioi > > > > On 7/7/16 6:08 PM, Jiangli Zhou wrote: >> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >> bug: JDK-8141341 >> >> With -Xshare:on >> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >> >> With -Xshare:auto >> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >> >> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >> >> Thanks, >> Jiangli >> >> > From jiangli.zhou at oracle.com Fri Jul 8 18:18:41 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 11:18:41 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> Message-ID: Hi Karen, Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. Thanks, Jiangli > On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: > > Jiangli, > > Thank you so much for picking up this bug fix, I very much appreciate that. > > I agree with not quitting the vm on agent attach. > I actually think we also want the agent attach to succeed - see below. >> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >> >> (Adding serviceability-dev at openjdk.java.net) >> >> Hi Jiangli, >> >> I think the two blocks of >> >> if (RequireSharedSpaces) { >> tty->print_cr("An error has occurred while loading shared class."); >> tty->print_cr("Tool agent requires sharing to be disabled."); >> vm_exit(1); >> } >> >> should be removed. > I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, > but no forcing of using the shared spaces if there is an agent. >> >> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp > Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >> >> If the agent is attached later, after the VM has started, I think we should not quit the VM. > Totally agree - we should not quit the VM. > >> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >> >> jvmtiError >> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >> >> ... >> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >> + } >> record_class_file_load_hook_enabled(); >> } >> ? >> } >> > I was expecting the vm to continue running, letting the agent attach (customers really want to use these). > Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. > I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the > two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >> >> Thanks >> - Ioi > Jiangli: > > Minor code review comments: > > metaspace.cpp line 3181: CFHL-> CFLH > > metaspace.cpp: > I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. > I think it would make sense to do a bit more of that - e.g. cds_address appears to only be > use locally, so it also could be inside the #if INCLUDE_CDS. > Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? > > thanks, > Karen > >> >> >> >> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>> bug: JDK-8141341 >>> >>> With -Xshare:on >>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>> >>> With -Xshare:auto >>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>> >>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>> >>> Thanks, >>> Jiangli >>> >>> >> > From serguei.spitsyn at oracle.com Fri Jul 8 19:59:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Jul 2016 12:59:24 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <577F0866.2050606@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> Message-ID: <5780061C.9020500@oracle.com> Hi Jiangli, src/share/vm/memory/metaspace.cpp 3177 if (UseSharedSpaces) { 3178 FileMapInfo* mapinfo = new FileMapInfo(); 3179 3180 if (JvmtiExport::should_post_class_file_load_hook()) { 3181 // Currently CDS does not support JVMTI CFHL when loading shared class. 3182 // If JvmtiExport::should_post_class_file_load_hook is already enabled, 3183 // just disable UseSharedSpaces. 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be disabled."); 3185 } else { I understood, the FileMapInfo::fail_continue() will fail if the RequireSharedSpaces is enabled which is expected. Should the mapinfo be deallocated in the case FileMapInfo::fail_continue() is called? Also, there is a comment below. On 7/7/16 18:56, Ioi Lam wrote: > (Adding serviceability-dev at openjdk.java.net) > > Hi Jiangli, > > I think the two blocks of > > if (RequireSharedSpaces) { > tty->print_cr("An error has occurred while loading shared class."); > tty->print_cr("Tool agent requires sharing to be disabled."); > vm_exit(1); > } > > should be removed. > > If the agent is specified in the command line, the JVM start would be > aborted. This is already handled by your changes to > src/share/vm/memory/metaspace.cpp > > If the agent is attached later, after the VM has started, I think we > should not quit the VM. Consider this scenario -- a production server > could be running for a long time without issues using -Xshare:on, then > when the user attaches a diagnostic agent the JVM suddenly quits. I > think it's better to cause the agent attachment to fail with something > like > > jvmtiError > JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent > event_type, jthread event_thread, ...) { > > ... > if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { > + if (RequireSharedSpaces && !universe::is_bootstraping()) { > + tty->print_cr("Tool agent that requires > JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after > JVM has started"); > + return JVMTI_ERROR_ILLEGAL_ARGUMENT; > + } > record_class_file_load_hook_enabled(); > } > ... > } This is a good concern and suggestion. We may need more sophisticated handling for this. Sorry, I did not notice it earlier. There is a capability can_generate_all_class_hook_events. We already have this in the prims/jvmtiManageCapabilities.cpp: // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } If enabled can_generate_all_class_hook_events sets the flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: JvmtiExport::set_can_modify_any_class( avail.can_generate_breakpoint_events || avail.can_generate_all_class_hook_events); The flag JvmtiExport::can_modify_any_class() is used here: char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in use (debugging enabled), we must map the address space RW if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) { si->_read_only = false; } So, I'm thinking if we could just skip the CFLH events for the shared classes if the capability can_generate_all_class_hook_events is not enabled and continue posting the events for non-shared classes. Then we do not need to tweak the SetEventNotificationMode() implementation. Otherwise, the fragment above may need to be updated too. To summarize, I understood that the current approach/plan for JDK 9 is: - Disable the CDS if detected early that the CFLH events are enabled - Skip the CFLH events for shared classes if CFLH is enabled late Is this right? Is it the same as in the JDK 8? Thanks, Serguei > Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >> Please review the following webrev that disables CDS when >> JvmtiExport::should_post_class_file_load_hook() is enabled at >> runtime. webrev: >> http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: >> JDK-8141341 With >> -Xshare:on If -Xshare:on is used and >> JvmtiExport::should_post_class_file_load_hook() is required, the VM >> now reports "Tool agent requires sharing to be disabled? and >> terminates. This is the same behavior as jdk8. With -Xshare:auto The >> change in meatspace.cpp is to detect the case where >> JvmtiExport::should_post_class_file_load_hook() is enabled very early >> during JVM initialization. In that case, we disable CDS entirely, >> including all shared classes, symbols, and Strings objects. The >> change in systemDictionary.cpp is to detect the cases where >> JvmtiExport::should_post_class_file_load_hook() is enabled late, >> which include agent dynamically attached at runtime. In those cases, >> JVM does not allow loading classes from the shared archive. The >> shared symbols and Strings can still be used. Thanks, Jiangli From serguei.spitsyn at oracle.com Fri Jul 8 20:57:06 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Jul 2016 13:57:06 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <5780061C.9020500@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <5780061C.9020500@oracle.com> Message-ID: <578013A2.9000103@oracle.com> On 7/8/16 12:59, serguei.spitsyn at oracle.com wrote: > Hi Jiangli, > > > src/share/vm/memory/metaspace.cpp > > 3177 if (UseSharedSpaces) { > 3178 FileMapInfo* mapinfo = new FileMapInfo(); > 3179 > 3180 if (JvmtiExport::should_post_class_file_load_hook()) { > 3181 // Currently CDS does not support JVMTI CFHL when loading shared > class. > 3182 // If JvmtiExport::should_post_class_file_load_hook is already > enabled, > 3183 // just disable UseSharedSpaces. > 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be > disabled."); > 3185 } else { > > I understood, the FileMapInfo::fail_continue() will fail if the > RequireSharedSpaces is enabled which is expected. > Should the mapinfo be deallocated in the case > FileMapInfo::fail_continue() is called? > > Also, there is a comment below. > > > On 7/7/16 18:56, Ioi Lam wrote: >> (Adding serviceability-dev at openjdk.java.net) >> >> Hi Jiangli, >> >> I think the two blocks of >> >> if (RequireSharedSpaces) { >> tty->print_cr("An error has occurred while loading shared >> class."); >> tty->print_cr("Tool agent requires sharing to be disabled."); >> vm_exit(1); >> } >> >> should be removed. >> >> If the agent is specified in the command line, the JVM start would be >> aborted. This is already handled by your changes to >> src/share/vm/memory/metaspace.cpp >> >> If the agent is attached later, after the VM has started, I think we >> should not quit the VM. Consider this scenario -- a production server >> could be running for a long time without issues using -Xshare:on, >> then when the user attaches a diagnostic agent the JVM suddenly >> quits. I think it's better to cause the agent attachment to fail >> with something like >> >> jvmtiError >> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent >> event_type, jthread event_thread, ...) { >> >> ... >> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >> + tty->print_cr("Tool agent that requires >> JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after >> JVM has started"); >> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >> + } >> record_class_file_load_hook_enabled(); >> } >> ... >> } > > > This is a good concern and suggestion. > We may need more sophisticated handling for this. > Sorry, I did not notice it earlier. > > There is a capability can_generate_all_class_hook_events. > We already have this in the prims/jvmtiManageCapabilities.cpp: > > // if the capability sets are initialized in the onload phase then // > it happens before class data sharing (CDS) is initialized. If it // > turns out that CDS gets disabled then we must adjust the always // > capabilities. To ensure a consistent view of the capabililties // > anything we add here should already be in the onload set. void > JvmtiManageCapabilities::recompute_always_capabilities() { if > (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; > jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } > } If enabled can_generate_all_class_hook_events sets the > flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: > JvmtiExport::set_can_modify_any_class( > avail.can_generate_breakpoint_events || > avail.can_generate_all_class_hook_events); The flag > JvmtiExport::can_modify_any_class() is used here: > > char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in > use (debugging enabled), we must map the address space RW if > (JvmtiExport::can_modify_any_class() || > JvmtiExport::can_walk_any_space()) { si->_read_only = false; } > So, I'm thinking if we could just skip the CFLH events for the shared > classes if the capability can_generate_all_class_hook_events is not > enabled and continue posting the events for non-shared classes. Then > we do not need to tweak the SetEventNotificationMode() implementation. > Otherwise, the fragment above may need to be updated too. > To summarize, I understood that the current approach/plan for JDK 9 is: > - Disable the CDS if detected early that the CFLH events are enabled > - Skip the CFLH events for shared classes if CFLH is enabled late > Is this right? Is it the same as in the JDK 8? I realized, it is not correct. Sorry for the confusion. The above contradicts with the statement from Jiangli: > The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. So, we want to disallow loading classes from the shared archive if the CFLH events are enabled late. I'm still in process of reviewing. Thanks, Serguei > Thanks, Serguei >> Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>> Please review the following webrev that disables CDS when >>> JvmtiExport::should_post_class_file_load_hook() is enabled at >>> runtime. webrev: >>> http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: >>> JDK-8141341 With >>> -Xshare:on If -Xshare:on is used and >>> JvmtiExport::should_post_class_file_load_hook() is required, the VM >>> now reports "Tool agent requires sharing to be disabled? and >>> terminates. This is the same behavior as jdk8. With -Xshare:auto The >>> change in meatspace.cpp is to detect the case where >>> JvmtiExport::should_post_class_file_load_hook() is enabled very >>> early during JVM initialization. In that case, we disable CDS >>> entirely, including all shared classes, symbols, and Strings >>> objects. The change in systemDictionary.cpp is to detect the cases >>> where JvmtiExport::should_post_class_file_load_hook() is enabled >>> late, which include agent dynamically attached at runtime. In those >>> cases, JVM does not allow loading classes from the shared archive. >>> The shared symbols and Strings can still be used. Thanks, Jiangli From ioi.lam at oracle.com Sat Jul 9 00:47:27 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 08 Jul 2016 17:47:27 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> Message-ID: <5780499F.3020304@oracle.com> Hi Jiangli, I agree what what Karen has said. If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. Also, maybe this check can also be removed? 1247 instanceKlassHandle SystemDictionary::load_shared_class( 1248 Symbol* class_name, Handle class_loader, TRAPS) { 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< Since the same check is already done in the "inner" load_shared_class() method. Thanks - Ioi On 7/8/16 11:18 AM, Jiangli Zhou wrote: > Hi Karen, > > Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. > > Thanks, > Jiangli > >> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >> >> Jiangli, >> >> Thank you so much for picking up this bug fix, I very much appreciate that. >> >> I agree with not quitting the vm on agent attach. >> I actually think we also want the agent attach to succeed - see below. >>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>> >>> (Adding serviceability-dev at openjdk.java.net) >>> >>> Hi Jiangli, >>> >>> I think the two blocks of >>> >>> if (RequireSharedSpaces) { >>> tty->print_cr("An error has occurred while loading shared class."); >>> tty->print_cr("Tool agent requires sharing to be disabled."); >>> vm_exit(1); >>> } >>> >>> should be removed. >> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >> but no forcing of using the shared spaces if there is an agent. >>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >> Totally agree - we should not quit the VM. >> >>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>> >>> jvmtiError >>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>> >>> ... >>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>> + } >>> record_class_file_load_hook_enabled(); >>> } >>> ? >>> } >>> >> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>> Thanks >>> - Ioi >> Jiangli: >> >> Minor code review comments: >> >> metaspace.cpp line 3181: CFHL-> CFLH >> >> metaspace.cpp: >> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >> use locally, so it also could be inside the #if INCLUDE_CDS. >> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >> >> thanks, >> Karen >> >>> >>> >>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>> >>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>> bug: JDK-8141341 >>>> >>>> With -Xshare:on >>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>> >>>> With -Xshare:auto >>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>> >>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> From jiangli.zhou at oracle.com Sat Jul 9 01:04:48 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 18:04:48 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <5780061C.9020500@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <5780061C.9020500@oracle.com> Message-ID: <6E898B08-564E-454E-9586-D50F2744E714@oracle.com> Hi Serguei, Thank you for looking into the changes. With Ioi and Karen?s suggestion for dynamically attached agent and -Xshare:on, I?m reworking the changes. I?m planning to remove the check below and do that in a later place. I?ll post the new webrev next week. Thanks, Jiangli > On Jul 8, 2016, at 12:59 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jiangli, > > > src/share/vm/memory/metaspace.cpp > > 3177 if (UseSharedSpaces) { > 3178 FileMapInfo* mapinfo = new FileMapInfo(); > 3179 > 3180 if (JvmtiExport::should_post_class_file_load_hook()) { > 3181 // Currently CDS does not support JVMTI CFHL when loading shared class. > 3182 // If JvmtiExport::should_post_class_file_load_hook is already enabled, > 3183 // just disable UseSharedSpaces. > 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be disabled."); > 3185 } else { > > > I understood, the FileMapInfo::fail_continue() will fail if the RequireSharedSpaces is enabled which is expected. > Should the mapinfo be deallocated in the case FileMapInfo::fail_continue() is called? > > Also, there is a comment below. > > > On 7/7/16 18:56, Ioi Lam wrote: >> (Adding serviceability-dev at openjdk.java.net) >> >> Hi Jiangli, >> >> I think the two blocks of >> >> if (RequireSharedSpaces) { >> tty->print_cr("An error has occurred while loading shared class."); >> tty->print_cr("Tool agent requires sharing to be disabled."); >> vm_exit(1); >> } >> >> should be removed. >> >> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >> >> If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >> >> jvmtiError >> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >> >> ... >> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >> + } >> record_class_file_load_hook_enabled(); >> } >> ... >> } > > > This is a good concern and suggestion. > We may need more sophisticated handling for this. > Sorry, I did not notice it earlier. > > There is a capability can_generate_all_class_hook_events. > We already have this in the prims/jvmtiManageCapabilities.cpp: > > // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } If enabled can_generate_all_class_hook_events sets the flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: > JvmtiExport::set_can_modify_any_class( avail.can_generate_breakpoint_events || avail.can_generate_all_class_hook_events); The flag JvmtiExport::can_modify_any_class() is used here: > > char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in use (debugging enabled), we must map the address space RW if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) { si->_read_only = false; } > > So, I'm thinking if we could just skip the CFLH events for the shared classes if the capability can_generate_all_class_hook_events is not enabled and continue posting the events for non-shared classes. Then we do not need to tweak the SetEventNotificationMode() implementation. Otherwise, the fragment above may need to be updated too. To summarize, I understood that the current approach/plan for JDK 9 is: - Disable the CDS if detected early that the CFLH events are enabled - Skip the CFLH events for shared classes if CFLH is enabled late Is this right? Is it the same as in the JDK 8? Thanks, Serguei >> Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: JDK-8141341 With -Xshare:on If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. With -Xshare:auto The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. Thanks, Jiangli From jiangli.zhou at oracle.com Sat Jul 9 01:14:05 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 18:14:05 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <5780499F.3020304@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> Message-ID: Hi Ioi, > On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: > > Hi Jiangli, > > I agree what what Karen has said. > > If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. > > We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. Agreed. > > Also, maybe this check can also be removed? > > 1247 instanceKlassHandle SystemDictionary::load_shared_class( > 1248 Symbol* class_name, Handle class_loader, TRAPS) { > 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< > > Since the same check is already done in the "inner" load_shared_class() method. I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. Thanks, Jiangli > > Thanks > - Ioi > > > On 7/8/16 11:18 AM, Jiangli Zhou wrote: >> Hi Karen, >> >> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >> >> Thanks, >> Jiangli >> >>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>> >>> Jiangli, >>> >>> Thank you so much for picking up this bug fix, I very much appreciate that. >>> >>> I agree with not quitting the vm on agent attach. >>> I actually think we also want the agent attach to succeed - see below. >>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>> >>>> (Adding serviceability-dev at openjdk.java.net) >>>> >>>> Hi Jiangli, >>>> >>>> I think the two blocks of >>>> >>>> if (RequireSharedSpaces) { >>>> tty->print_cr("An error has occurred while loading shared class."); >>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>> vm_exit(1); >>>> } >>>> >>>> should be removed. >>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>> but no forcing of using the shared spaces if there is an agent. >>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>> Totally agree - we should not quit the VM. >>> >>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>> >>>> jvmtiError >>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>> >>>> ... >>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>> + } >>>> record_class_file_load_hook_enabled(); >>>> } >>>> ? >>>> } >>>> >>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>> Thanks >>>> - Ioi >>> Jiangli: >>> >>> Minor code review comments: >>> >>> metaspace.cpp line 3181: CFHL-> CFLH >>> >>> metaspace.cpp: >>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>> use locally, so it also could be inside the #if INCLUDE_CDS. >>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>> >>> thanks, >>> Karen >>> >>>> >>>> >>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>> bug: JDK-8141341 >>>>> >>>>> With -Xshare:on >>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>> >>>>> With -Xshare:auto >>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>> >>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> > From serguei.spitsyn at oracle.com Sat Jul 9 04:39:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Jul 2016 21:39:25 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <6E898B08-564E-454E-9586-D50F2744E714@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <5780061C.9020500@oracle.com> <6E898B08-564E-454E-9586-D50F2744E714@oracle.com> Message-ID: <57807FFD.1030100@oracle.com> Hi Jiangli, Ok, I'll wait for the next webrev version. Thanks, Serguei On 7/8/16 18:04, Jiangli Zhou wrote: > Hi Serguei, > > Thank you for looking into the changes. With Ioi and Karen?s suggestion for dynamically attached agent and -Xshare:on, I?m reworking the changes. I?m planning to remove the check below and do that in a later place. I?ll post the new webrev next week. > > Thanks, > Jiangli > >> On Jul 8, 2016, at 12:59 PM, serguei.spitsyn at oracle.com wrote: >> >> Hi Jiangli, >> >> >> src/share/vm/memory/metaspace.cpp >> >> 3177 if (UseSharedSpaces) { >> 3178 FileMapInfo* mapinfo = new FileMapInfo(); >> 3179 >> 3180 if (JvmtiExport::should_post_class_file_load_hook()) { >> 3181 // Currently CDS does not support JVMTI CFHL when loading shared class. >> 3182 // If JvmtiExport::should_post_class_file_load_hook is already enabled, >> 3183 // just disable UseSharedSpaces. >> 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be disabled."); >> 3185 } else { >> >> >> I understood, the FileMapInfo::fail_continue() will fail if the RequireSharedSpaces is enabled which is expected. >> Should the mapinfo be deallocated in the case FileMapInfo::fail_continue() is called? >> >> Also, there is a comment below. >> >> >> On 7/7/16 18:56, Ioi Lam wrote: >>> (Adding serviceability-dev at openjdk.java.net) >>> >>> Hi Jiangli, >>> >>> I think the two blocks of >>> >>> if (RequireSharedSpaces) { >>> tty->print_cr("An error has occurred while loading shared class."); >>> tty->print_cr("Tool agent requires sharing to be disabled."); >>> vm_exit(1); >>> } >>> >>> should be removed. >>> >>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>> >>> If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>> >>> jvmtiError >>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>> >>> ... >>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>> + } >>> record_class_file_load_hook_enabled(); >>> } >>> ... >>> } >> >> This is a good concern and suggestion. >> We may need more sophisticated handling for this. >> Sorry, I did not notice it earlier. >> >> There is a capability can_generate_all_class_hook_events. >> We already have this in the prims/jvmtiManageCapabilities.cpp: >> >> // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } If enabled can_generate_all_class_hook_events sets the flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: >> JvmtiExport::set_can_modify_any_class( avail.can_generate_breakpoint_events || avail.can_generate_all_class_hook_events); The flag JvmtiExport::can_modify_any_class() is used here: >> >> char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in use (debugging enabled), we must map the address space RW if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) { si->_read_only = false; } >> >> So, I'm thinking if we could just skip the CFLH events for the shared classes if the capability can_generate_all_class_hook_events is not enabled and continue posting the events for non-shared classes. Then we do not need to tweak the SetEventNotificationMode() implementation. Otherwise, the fragment above may need to be updated too. To summarize, I understood that the current approach/plan for JDK 9 is: - Disable the CDS if detected early that the CFLH events are enabled - Skip the CFLH events for shared classes if CFLH is enabled late Is this right? Is it the same as in the JDK 8? Thanks, Serguei >>> Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: JDK-8141341 With -Xshare:on If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. With -Xshare:auto The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. Thanks, Jiangli From dmitry.samersoff at oracle.com Mon Jul 11 08:22:38 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 11 Jul 2016 11:22:38 +0300 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> Message-ID: <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> PING ... -------- Forwarded Message -------- Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase Date: Wed, 6 Jul 2016 19:24:15 +0300 From: Dmitry Samersoff To: serviceability-dev at openjdk.java.net Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ All credentials belongs to Richard Reingruber, see mail thread (below) for details. http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Mon Jul 11 09:31:16 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Jul 2016 09:31:16 +0000 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> Message-ID: <51cd5f93473b44eeb889fb5c5212f5ad@DEWDFE13DE09.global.corp.sap> Hi Dmitry, thanks for looking at this issue. I think your fix will crash if thread->jvmti_thread_state(); returns NULL. Also, please add the #include with leading directory prims/ at the proper alphabetic position. Also, you could add the test Richard supplied, see below. Best regards, Goetz. --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/serviceability/jvmti/ExceptionCaughtOutOfPhaseAssertion.java Mon Jul 11 11:30:12 2016 +0200 @@ -0,0 +1,55 @@ +/* + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import java.security.AccessController; +import java.security.PrivilegedAction; + +/* + * @test + * @bug 8134434 + * @summary JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase + * @run main/othervm -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion + */ + +public class ExceptionCaughtOutOfPhaseAssertion { + public static void main(String[] args) { + PrivilegedAction action = new HotThrowingAction(); + System.out.println("### Warm-up"); + for(int i=0; i<11000; i++) { + try { + action.run(); // call run() to get it compiled + } catch(Throwable t) { /* ignored */ } + } + System.out.println("### Warm-up done"); + System.out.println("### Executing privileged action"); + try { + AccessController.doPrivileged(action); + } catch (Error e) { + } + } + public static class HotThrowingAction implements PrivilegedAction { + public Object run() { + throw new Error(); + } + } +} > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Dmitry Samersoff > Sent: Montag, 11. Juli 2016 10:23 > To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev runtime-dev at openjdk.java.net> > Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > > PING ... > > > -------- Forwarded Message -------- > Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > Date: Wed, 6 Jul 2016 19:24:15 +0300 > From: Dmitry Samersoff > To: serviceability-dev at openjdk.java.net > > > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ > > All credentials belongs to Richard Reingruber, see mail thread (below) > for details. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015- > August/019613.html > > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From Alan.Burlison at oracle.com Mon Jul 11 13:22:18 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 11 Jul 2016 14:22:18 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced Message-ID: <57839D8A.9050108@oracle.com> Hi, I'd like to ask for reviews for: JDK-8160997 Solaris: deprecated and interfaces should be replaced This is to remove code that was a workaround that was needed for Solaris 2.4. In 2.4 we implemented interfaces from the draft of POSIX.1c Draft 6 which then changed in the final POSIX release, and we were then stuck with the warts. For Solaris 11, defining the macro _POSIX_PTHREAD_SEMANTICS enables the 'official' POSIX information and means that the code which works on Linux etc also works the same on Solaris, so the Solaris-specific workarounds can be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8160997 Webrev: http://cr.openjdk.java.net/~dcubed/for_alanbur/8160997-webrev/0-jdk9-hs-all/ JPRT + the hotspot testset was clean. -- Alan Burlison -- From Alan.Bateman at oracle.com Mon Jul 11 13:31:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Jul 2016 14:31:33 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <57839D8A.9050108@oracle.com> References: <57839D8A.9050108@oracle.com> Message-ID: <0f604907-4fd8-a7a8-b373-b8c2bbb7e836@oracle.com> On 11/07/2016 14:22, Alan Burlison wrote: > Hi, I'd like to ask for reviews for: > > JDK-8160997 Solaris: deprecated and interfaces should > be replaced > > This is to remove code that was a workaround that was needed for > Solaris 2.4. In 2.4 we implemented interfaces from the draft of > POSIX.1c Draft 6 which then changed in the final POSIX release, and we > were then stuck with the warts. > > For Solaris 11, defining the macro _POSIX_PTHREAD_SEMANTICS enables > the 'official' POSIX information and means that the code which works > on Linux etc also works the same on Solaris, so the Solaris-specific > workarounds can be removed. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160997 > > Webrev: > http://cr.openjdk.java.net/~dcubed/for_alanbur/8160997-webrev/0-jdk9-hs-all/ > > The changes in the jdk repo look okay to me. Note that it's the tests in the jdk_core test group rather than the hotspot tests that will exercise this code. -Alan From coleen.phillimore at oracle.com Mon Jul 11 13:35:35 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Jul 2016 09:35:35 -0400 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> Message-ID: <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> Adding hotspot-compiler-dev since the change is in opto/runtime.cpp Coleen On 7/11/16 4:22 AM, Dmitry Samersoff wrote: > PING ... > > > -------- Forwarded Message -------- > Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > Date: Wed, 6 Jul 2016 19:24:15 +0300 > From: Dmitry Samersoff > To: serviceability-dev at openjdk.java.net > > > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ > > All credentials belongs to Richard Reingruber, see mail thread (below) > for details. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html > > > -Dmitry > From Alan.Burlison at oracle.com Mon Jul 11 13:45:20 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 11 Jul 2016 14:45:20 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <0f604907-4fd8-a7a8-b373-b8c2bbb7e836@oracle.com> References: <57839D8A.9050108@oracle.com> <0f604907-4fd8-a7a8-b373-b8c2bbb7e836@oracle.com> Message-ID: <5783A2F0.6020808@oracle.com> On 11/07/2016 14:31, Alan Bateman wrote: > The changes in the jdk repo look okay to me. Note that it's the tests in > the jdk_core test group rather than the hotspot tests that will exercise > this code. OK, I'll set a test run going - thanks! -- Alan Burlison -- From dmitry.samersoff at oracle.com Mon Jul 11 13:51:02 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 11 Jul 2016 16:51:02 +0300 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> Message-ID: <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> Everybody, Updated webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/ Testcase added. Goetz's concerns addressed. -Dmitry On 2016-07-11 16:35, Coleen Phillimore wrote: > Adding hotspot-compiler-dev since the change is in opto/runtime.cpp > > Coleen > > On 7/11/16 4:22 AM, Dmitry Samersoff wrote: >> PING ... >> >> >> -------- Forwarded Message -------- >> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires >> assert(_exception_caught == false) failed: _exception_caught is out of >> phase >> Date: Wed, 6 Jul 2016 19:24:15 +0300 >> From: Dmitry Samersoff >> To: serviceability-dev at openjdk.java.net >> >> >> Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ >> >> All credentials belongs to Richard Reingruber, see mail thread (below) >> for details. >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html >> >> >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Mon Jul 11 14:06:17 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Jul 2016 14:06:17 +0000 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> Message-ID: Hi Dmitry, thanks fort he fixed, looks good now. Best regards, Goetz. > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Montag, 11. Juli 2016 15:51 > To: Coleen Phillimore ; serviceability- > dev at openjdk.java.net; hotspot-runtime-dev dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net; > Lindenmaier, Goetz > Subject: Re: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > > Everybody, > > Updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/ > > Testcase added. Goetz's concerns addressed. > > -Dmitry > > > On 2016-07-11 16:35, Coleen Phillimore wrote: > > Adding hotspot-compiler-dev since the change is in opto/runtime.cpp > > > > Coleen > > > > On 7/11/16 4:22 AM, Dmitry Samersoff wrote: > >> PING ... > >> > >> > >> -------- Forwarded Message -------- > >> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires > >> assert(_exception_caught == false) failed: _exception_caught is out of > >> phase > >> Date: Wed, 6 Jul 2016 19:24:15 +0300 > >> From: Dmitry Samersoff > >> To: serviceability-dev at openjdk.java.net > >> > >> > >> Everybody, > >> > >> Please review the fix. > >> > >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ > >> > >> All credentials belongs to Richard Reingruber, see mail thread (below) > >> for details. > >> > >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015- > August/019613.html > >> > >> > >> > >> -Dmitry > >> > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Mon Jul 11 15:02:32 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 11 Jul 2016 09:02:32 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <57839D8A.9050108@oracle.com> References: <57839D8A.9050108@oracle.com> Message-ID: On 7/11/16 7:22 AM, Alan Burlison wrote: > Hi, I'd like to ask for reviews for: > > JDK-8160997 Solaris: deprecated and interfaces should > be replaced > > This is to remove code that was a workaround that was needed for > Solaris 2.4. In 2.4 we implemented interfaces from the draft of > POSIX.1c Draft 6 which then changed in the final POSIX release, and we > were then stuck with the warts. > > For Solaris 11, defining the macro _POSIX_PTHREAD_SEMANTICS enables > the 'official' POSIX information and means that the code which works > on Linux etc also works the same on Solaris, so the Solaris-specific > workarounds can be removed. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160997 > > Webrev: > http://cr.openjdk.java.net/~dcubed/for_alanbur/8160997-webrev/0-jdk9-hs-all/ > hotspot/src/os/solaris/vm/os_solaris.cpp No comments. hotspot/src/os/solaris/vm/perfMemory_solaris.cpp No comments. hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp No comments. hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp No comments. jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c No comments. jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c No comments. jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c So you added the &p parameter to the getpwuid_r(), but then you never check or use the returned 'p'. Other places that had both Solaris and non-Solaris variants had code like this: L479: if (result == 0 && p != NULL && L480: p->pw_name != NULL && *(p->pw_name) != '\0') { L481: name = JNU_NewStringPlatform(env, p->pw_name); L482: } Of course, this Solaris specific code checked the returned '&pwd' value because it didn't have an &p parameter. I don't this is a problem, especially since I don't understand why this function has both an '&pwd' param and an '&p' param, but I figured I would raise the question. jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c No comments. Thumbs up! I don't know what to think of the libjaas/Solaris.c code not using the possibly duplicate '&p' param. > > JPRT + the hotspot testset was clean. > If I remember correctly, you also ran a regular JPRT test job (without -testset hotspot). I believe that the regular job runs JDK focused testing, but I'd have to look at the JPRT job to be sure. Dan From Alan.Burlison at oracle.com Mon Jul 11 16:16:05 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 11 Jul 2016 17:16:05 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> Message-ID: <5783C645.9010709@oracle.com> On 11/07/2016 16:02, Daniel D. Daugherty wrote: > jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c > So you added the &p parameter to the getpwuid_r(), but > then you never check or use the returned 'p'. > > Other places that had both Solaris and non-Solaris variants > had code like this: > > L479: if (result == 0 && p != NULL && > L480: p->pw_name != NULL && *(p->pw_name) != '\0') { > L481: name = JNU_NewStringPlatform(env, p->pw_name); > L482: } > > Of course, this Solaris specific code checked the returned > '&pwd' value because it didn't have an &p parameter. I don't > this is a problem, especially since I don't understand why > this function has both an '&pwd' param and an '&p' param, > but I figured I would raise the question. Ah, the difference between the POSIX draft & final versions isn't just a new parameter, they also changed the return type - ugh. I think the not null/empty check for pw_name is overkill but a closer look a the manpage suggests that the check for a non-zero result should also be accompanied by a check for a non-null value in p: The getpwnam_r() and getpwuid_r() functions can return 0 in the case where the requested entry is not found. The application needs to check the return value and that the result pointer is non-null. Otherwise, an error value is returned to indicate the error. So I think the code in the patch should be: if (getpwuid_r(getuid(), &pwd, pwd_buf, sizeof(pwd_buf), &p) != 0 && p != NULL && getgroups(numSuppGroups, groups) != -1) { The preceding memset() isn't necessary but does no harm. And while I'm in there I notice that the size of pw_buf is hardcoded, it should be whatever is returned by sysconf(_SC_GETPW_R_SIZE_MAX). That's actually 1024 but to be future-proof it should really use sysconf() - I'll fix that as well, and check the other files for the same sort of issue, and then redo the webrev and the tests. > jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c > No comments. > > Thumbs up! I don't know what to think of the libjaas/Solaris.c > code not using the possibly duplicate '&p' param. >> >> JPRT + the hotspot testset was clean. >> > > If I remember correctly, you also ran a regular JPRT test job > (without -testset hotspot). I believe that the regular job > runs JDK focused testing, but I'd have to look at the JPRT > job to be sure. I'll need to rerun them anyway after addressing the above issues, if there are other ones you'd like me to run then just let me know. Thanks, -- Alan Burlison -- From daniel.daugherty at oracle.com Mon Jul 11 16:31:00 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 11 Jul 2016 10:31:00 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5783C645.9010709@oracle.com> References: <57839D8A.9050108@oracle.com> <5783C645.9010709@oracle.com> Message-ID: On 7/11/16 10:16 AM, Alan Burlison wrote: > On 11/07/2016 16:02, Daniel D. Daugherty wrote: > >> jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c >> So you added the &p parameter to the getpwuid_r(), but >> then you never check or use the returned 'p'. >> >> Other places that had both Solaris and non-Solaris variants >> had code like this: >> >> L479: if (result == 0 && p != NULL && >> L480: p->pw_name != NULL && *(p->pw_name) != '\0') { >> L481: name = JNU_NewStringPlatform(env, p->pw_name); >> L482: } >> >> Of course, this Solaris specific code checked the returned >> '&pwd' value because it didn't have an &p parameter. I don't >> this is a problem, especially since I don't understand why >> this function has both an '&pwd' param and an '&p' param, >> but I figured I would raise the question. > > Ah, the difference between the POSIX draft & final versions isn't just > a new parameter, they also changed the return type - ugh. I think the > not null/empty check for pw_name is overkill but a closer look a the > manpage suggests that the check for a non-zero result should also be > accompanied by a check for a non-null value in p: > > The getpwnam_r() and getpwuid_r() functions can return 0 in > the case > where the requested entry is not found. The application needs > to check > the return value and that the result pointer is non-null. > Otherwise, an > error value is returned to indicate the error. > > So I think the code in the patch should be: > > if (getpwuid_r(getuid(), &pwd, pwd_buf, sizeof(pwd_buf), &p) != 0 > && p != NULL && > getgroups(numSuppGroups, groups) != -1) { > > The preceding memset() isn't necessary but does no harm. > > And while I'm in there I notice that the size of pw_buf is hardcoded, > it should be whatever is returned by sysconf(_SC_GETPW_R_SIZE_MAX). > That's actually 1024 but to be future-proof it should really use > sysconf() - I'll fix that as well, and check the other files for the > same sort of issue, and then redo the webrev and the tests. Let me know when you're ready and I'll upload a new webrev for you... sorry this has gotten so messy... Dan > >> jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c >> No comments. >> >> Thumbs up! I don't know what to think of the libjaas/Solaris.c >> code not using the possibly duplicate '&p' param. >>> >>> JPRT + the hotspot testset was clean. >>> >> >> If I remember correctly, you also ran a regular JPRT test job >> (without -testset hotspot). I believe that the regular job >> runs JDK focused testing, but I'd have to look at the JPRT >> job to be sure. > > I'll need to rerun them anyway after addressing the above issues, if > there are other ones you'd like me to run then just let me know. > > Thanks, > From volker.simonis at gmail.com Mon Jul 11 16:41:12 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 11 Jul 2016 18:41:12 +0200 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5783C645.9010709@oracle.com> References: <57839D8A.9050108@oracle.com> <5783C645.9010709@oracle.com> Message-ID: Hi Alan, you write that "for Solaris 11, _POSIX_PTHREAD_SEMANTICS enables the 'official' POSIX" semantics. Is this strictly true only for Solaris 11 or also for Solaris 10 already. I know this question is not directly related to your change which only applies to jdk9, but we may have to downport this change to older Solaris releases so if you have any experience with _POSIX_PTHREAD_SEMANTICS on Solaris 10 it would be good to know. Besides that, could you please also fix the following bits: hotspot/src/os/solaris/vm/perfMemory_solaris.cpp - why do we need: +#if defined(SOLARIS) here. I think this file is always compiled with -DSOLARIS jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c - can you please use: #if defined(__solaris__) (as you did in ProcessHandleImpl_unix.c) instead of: #if defined(SOLARIS) In hotspot code it is more common to use our own platform defines from the command line whereas in the jdk repository we usually use the defualt system defines for the various platforms. Thank you and best regards, Volker On Mon, Jul 11, 2016 at 6:16 PM, Alan Burlison wrote: > On 11/07/2016 16:02, Daniel D. Daugherty wrote: > >> jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c >> So you added the &p parameter to the getpwuid_r(), but >> then you never check or use the returned 'p'. >> >> Other places that had both Solaris and non-Solaris variants >> had code like this: >> >> L479: if (result == 0 && p != NULL && >> L480: p->pw_name != NULL && *(p->pw_name) != '\0') { >> L481: name = JNU_NewStringPlatform(env, p->pw_name); >> L482: } >> >> Of course, this Solaris specific code checked the returned >> '&pwd' value because it didn't have an &p parameter. I don't >> this is a problem, especially since I don't understand why >> this function has both an '&pwd' param and an '&p' param, >> but I figured I would raise the question. > > > Ah, the difference between the POSIX draft & final versions isn't just a new > parameter, they also changed the return type - ugh. I think the not > null/empty check for pw_name is overkill but a closer look a the manpage > suggests that the check for a non-zero result should also be accompanied by > a check for a non-null value in p: > > The getpwnam_r() and getpwuid_r() functions can return 0 in the > case > where the requested entry is not found. The application needs to > check > the return value and that the result pointer is non-null. Otherwise, > an > error value is returned to indicate the error. > > So I think the code in the patch should be: > > if (getpwuid_r(getuid(), &pwd, pwd_buf, sizeof(pwd_buf), &p) != 0 && p > != NULL && > getgroups(numSuppGroups, groups) != -1) { > > The preceding memset() isn't necessary but does no harm. > > And while I'm in there I notice that the size of pw_buf is hardcoded, it > should be whatever is returned by sysconf(_SC_GETPW_R_SIZE_MAX). That's > actually 1024 but to be future-proof it should really use sysconf() - I'll > fix that as well, and check the other files for the same sort of issue, and > then redo the webrev and the tests. > >> jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c >> No comments. >> >> Thumbs up! I don't know what to think of the libjaas/Solaris.c >> code not using the possibly duplicate '&p' param. >>> >>> >>> JPRT + the hotspot testset was clean. >>> >> >> If I remember correctly, you also ran a regular JPRT test job >> (without -testset hotspot). I believe that the regular job >> runs JDK focused testing, but I'd have to look at the JPRT >> job to be sure. > > > I'll need to rerun them anyway after addressing the above issues, if there > are other ones you'd like me to run then just let me know. > > Thanks, > > -- > Alan Burlison > -- From Alan.Burlison at oracle.com Mon Jul 11 16:47:12 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 11 Jul 2016 17:47:12 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <5783C645.9010709@oracle.com> Message-ID: <5783CD90.9080708@oracle.com> On 11/07/2016 17:31, Daniel D. Daugherty wrote: > Let me know when you're ready and I'll upload a new webrev > for you... sorry this has gotten so messy... Thank you, will do - and no worries, the whole point of the exercise is to give the Solaris platform support code a bit of a polish and try to sort out some of the older, messier bits of code. It's absolutely worth investing the time to make sure the changes are the best we can come up with. Thanks, -- Alan Burlison -- From Alan.Burlison at oracle.com Mon Jul 11 16:53:19 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 11 Jul 2016 17:53:19 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <5783C645.9010709@oracle.com> Message-ID: <5783CEFF.1080206@oracle.com> On 11/07/2016 17:41, Volker Simonis wrote: > you write that "for Solaris 11, _POSIX_PTHREAD_SEMANTICS enables the > 'official' POSIX" semantics. Is this strictly true only for Solaris 11 > or also for Solaris 10 already. I know this question is not directly > related to your change which only applies to jdk9, but we may have to > downport this change to older Solaris releases so if you have any > experience with _POSIX_PTHREAD_SEMANTICS on Solaris 10 it would be > good to know. It is true for Solaris 10 and even Solaris 9. > Besides that, could you please also fix the following bits: > > hotspot/src/os/solaris/vm/perfMemory_solaris.cpp > - why do we need: > > +#if defined(SOLARIS) > > here. I think this file is always compiled with -DSOLARIS I was just being (over) cautious, I'll make the change you suggest, thanks. > jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c > jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c > - can you please use: > #if defined(__solaris__) > (as you did in ProcessHandleImpl_unix.c) instead of: > #if defined(SOLARIS) Sure. > In hotspot code it is more common to use our own platform defines from > the command line whereas in the jdk repository we usually use the > defualt system defines for the various platforms. Ah right, I've seen a mix of styles and hadn't yet figured out the rule for which to use where, thanks for the guidance :-) -- Alan Burlison -- From vladimir.kozlov at oracle.com Mon Jul 11 16:57:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Jul 2016 09:57:52 -0700 Subject: [9] RFR (S): 8098573: Compiler accesses to shared archive fail if archive is remapped In-Reply-To: <5783BAC2.5090307@oracle.com> References: <5783BAC2.5090307@oracle.com> Message-ID: <8c081f13-d41c-f467-153e-e21b34e50c75@oracle.com> Looks good to me. CCing to runtime for them to look. Thanks, Vladimir On 7/11/16 8:26 AM, Zolt?n Maj? wrote: > Hi, > > > please review the fix for JDK-8098573. > > https://bugs.openjdk.java.net/browse/JDK-8098573 > > Problem: The VM crashes with a SIGSEGV due to the compiler accessing symbol information in a (AppCDS) shared archive. I > was not able to reproduce the crash, but there is evidence to suggest that the crash is caused by the *compiler > accessing the shared archive when not in VM state*: While the compiler is reading form the shared archive, an ongoing > VM_RedefineClasses operation remaps the shared archive (with different permissions but at the same address), which is > the only likely cause of the SEGV_MAPERR in the compiler. For more details please see [1]. > > Solution: Change the destructor ciEnv::~ciEnv() to access symbols in VM state (similar to other places in the compiler > accessing symbol information). > > Webrev: > http://cr.openjdk.java.net/~zmajo/8098573/webrev.00/ > > Testing: > - JPRT; > - RBT testing w/ all hotspot tests is in progress. > > Thank you! > > Best regards, > > > Zoltan > > [1] > https://bugs.openjdk.java.net/browse/JDK-8098573?focusedCommentId=13971831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13971831 > From gerard.ziemski at oracle.com Mon Jul 11 17:25:41 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 11 Jul 2016 12:25:41 -0500 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 Message-ID: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> hi all, Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. Currently all we print is just the warning's 1st line below, but with this fix we show the following: ----------------------------- Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 Java system dictionary (table_size=1009, classes=484) ^ indicates that initiating loader is different from defining loader 1st number shows bucket index 2nd number shows chain index within a bucket 3rd number shows hit percentage of the bucket 4th number shows hash index 0: 1: 2: 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader 5: . . . 1003: 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader 1005: 1006: 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader Top 16 buckets: 546: hits 2.76% 183: hits 0.87% 969: hits 2.37%s 281: hits 0.95% 957: hits 1.73% 571: hits 16.67% 221: hits 0.98% 505: hits 0.84% 727: hits 1.28% 414: hits 1.73% 569: hits 4.89% 245: hits 0.89% 253: hits 1.34% 135: hits 0.95% 457: hits 0.87% 348: hits 1.23% Protection domain cache table (table_size=2017, classes=1) entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 ----------------------------- We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 Passes JPRT hotspot. cheers From poonam.bajaj at oracle.com Mon Jul 11 19:28:35 2016 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 11 Jul 2016 12:28:35 -0700 Subject: RFR (8u): 8042660: vm/mlvm/anonloader/stress/byteMutation failed with: assert(index >=0 && index < _length) failed: symbol index overflow Message-ID: Hello, Please review these changes that backport the fix of '8042660: vm/mlvm/anonloader/stress/byteMutation failed with: assert(index >=0 && index < _length) failed: symbol index overflow' to 8u. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8042660 Webrev:http://cr.openjdk.java.net/~poonam/8042660/webrev.8u.00/ Testing: - JPRT - Tested the testcase BadNameAndType with the fastdebug build of the fixed 8u JDK. Thanks, Poonam From cthalinger at twitter.com Tue Jul 12 00:24:05 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 11 Jul 2016 14:24:05 -1000 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> References: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> Message-ID: <3D8517A0-A501-4858-818B-EAF511224E01@twitter.com> Is this temporary or do you want to keep this code? If you want to keep it debug_only should be upper-case DEBUG_ONLY. > On Jul 11, 2016, at 7:25 AM, Gerard Ziemski wrote: > > hi all, > > Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. > > Currently all we print is just the warning's 1st line below, but with this fix we show the following: > > ----------------------------- > Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 > Java system dictionary (table_size=1009, classes=484) > ^ indicates that initiating loader is different from defining loader > 1st number shows bucket index > 2nd number shows chain index within a bucket > 3rd number shows hit percentage of the bucket > 4th number shows hash index > 0: > 1: > 2: > 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader > 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader > 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader > 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader > 5: > . > . > . > 1003: > 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader > 1005: > 1006: > 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader > 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader > > Top 16 buckets: > 546: hits 2.76% > 183: hits 0.87% > 969: hits 2.37%s > 281: hits 0.95% > 957: hits 1.73% > 571: hits 16.67% > 221: hits 0.98% > 505: hits 0.84% > 727: hits 1.28% > 414: hits 1.73% > 569: hits 4.89% > 245: hits 0.89% > 253: hits 1.34% > 135: hits 0.95% > 457: hits 0.87% > 348: hits 1.23% > > Protection domain cache table (table_size=2017, classes=1) > entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 > ----------------------------- > > We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. > > In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. > > open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 > bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > > Passes JPRT hotspot. > > > cheers > From david.holmes at oracle.com Tue Jul 12 00:51:37 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 10:51:37 +1000 Subject: [9] RFR (S): 8098573: Compiler accesses to shared archive fail if archive is remapped In-Reply-To: <8c081f13-d41c-f467-153e-e21b34e50c75@oracle.com> References: <5783BAC2.5090307@oracle.com> <8c081f13-d41c-f467-153e-e21b34e50c75@oracle.com> Message-ID: On 12/07/2016 2:57 AM, Vladimir Kozlov wrote: > Looks good to me. > > CCing to runtime for them to look. Seems fine to me. Thanks, David > Thanks, > Vladimir > > On 7/11/16 8:26 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the fix for JDK-8098573. >> >> https://bugs.openjdk.java.net/browse/JDK-8098573 >> >> Problem: The VM crashes with a SIGSEGV due to the compiler accessing >> symbol information in a (AppCDS) shared archive. I >> was not able to reproduce the crash, but there is evidence to suggest >> that the crash is caused by the *compiler >> accessing the shared archive when not in VM state*: While the compiler >> is reading form the shared archive, an ongoing >> VM_RedefineClasses operation remaps the shared archive (with different >> permissions but at the same address), which is >> the only likely cause of the SEGV_MAPERR in the compiler. For more >> details please see [1]. >> >> Solution: Change the destructor ciEnv::~ciEnv() to access symbols in >> VM state (similar to other places in the compiler >> accessing symbol information). >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8098573/webrev.00/ >> >> Testing: >> - JPRT; >> - RBT testing w/ all hotspot tests is in progress. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] >> https://bugs.openjdk.java.net/browse/JDK-8098573?focusedCommentId=13971831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13971831 >> >> From david.holmes at oracle.com Tue Jul 12 03:44:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 13:44:28 +1000 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> References: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> Message-ID: <7bd93661-b50a-ab4c-2641-b81e5ffbcf9c@oracle.com> Hi Gerard, Please include the bug number in the RFR subject - thanks. Adding the additional diagnostic info seems okay for debug builds. Two style nits with src/share/vm/classfile/dictionary.cpp 1. As Christian mentioned DEBUG_ONLY is preferred, but debug_only is presently used. I would not be adverse to going a global replace in this file in this case. 2. Please ensure there are spaces around operators, particularly in for loops e.g.: - good: 757 for (int i = 0; i < table_size(); i++) { - bad: 753 for (int i=0; i hi all, > > Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. > > Currently all we print is just the warning's 1st line below, but with this fix we show the following: > > ----------------------------- > Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 > Java system dictionary (table_size=1009, classes=484) > ^ indicates that initiating loader is different from defining loader > 1st number shows bucket index > 2nd number shows chain index within a bucket > 3rd number shows hit percentage of the bucket > 4th number shows hash index > 0: > 1: > 2: > 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader > 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader > 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader > 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader > 5: > . > . > . > 1003: > 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader > 1005: > 1006: > 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader > 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader > > Top 16 buckets: > 546: hits 2.76% > 183: hits 0.87% > 969: hits 2.37%s > 281: hits 0.95% > 957: hits 1.73% > 571: hits 16.67% > 221: hits 0.98% > 505: hits 0.84% > 727: hits 1.28% > 414: hits 1.73% > 569: hits 4.89% > 245: hits 0.89% > 253: hits 1.34% > 135: hits 0.95% > 457: hits 0.87% > 348: hits 1.23% > > Protection domain cache table (table_size=2017, classes=1) > entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 > ----------------------------- > > We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. > > In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. > > open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 > bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > > Passes JPRT hotspot. > > > cheers > From zoltan.majo at oracle.com Tue Jul 12 08:10:51 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 12 Jul 2016 10:10:51 +0200 Subject: [9] RFR (S): 8098573: Compiler accesses to shared archive fail if archive is remapped In-Reply-To: References: <5783BAC2.5090307@oracle.com> <8c081f13-d41c-f467-153e-e21b34e50c75@oracle.com> Message-ID: <5784A60B.4020004@oracle.com> Thank you, Vladimir and David, for the review! I'll push the fix today to the hs-comp repository. Best regards, Zoltan On 07/12/2016 02:51 AM, David Holmes wrote: > On 12/07/2016 2:57 AM, Vladimir Kozlov wrote: >> Looks good to me. >> >> CCing to runtime for them to look. > > Seems fine to me. > > Thanks, > David > >> Thanks, >> Vladimir >> >> On 7/11/16 8:26 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the fix for JDK-8098573. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8098573 >>> >>> Problem: The VM crashes with a SIGSEGV due to the compiler accessing >>> symbol information in a (AppCDS) shared archive. I >>> was not able to reproduce the crash, but there is evidence to suggest >>> that the crash is caused by the *compiler >>> accessing the shared archive when not in VM state*: While the compiler >>> is reading form the shared archive, an ongoing >>> VM_RedefineClasses operation remaps the shared archive (with different >>> permissions but at the same address), which is >>> the only likely cause of the SEGV_MAPERR in the compiler. For more >>> details please see [1]. >>> >>> Solution: Change the destructor ciEnv::~ciEnv() to access symbols in >>> VM state (similar to other places in the compiler >>> accessing symbol information). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zmajo/8098573/webrev.00/ >>> >>> Testing: >>> - JPRT; >>> - RBT testing w/ all hotspot tests is in progress. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> [1] >>> https://bugs.openjdk.java.net/browse/JDK-8098573?focusedCommentId=13971831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13971831 >>> >>> >>> From tobias.hartmann at oracle.com Tue Jul 12 12:34:00 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jul 2016 14:34:00 +0200 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> Message-ID: <5784E3B8.40401@oracle.com> Hi Goetz, On 06.07.2016 00:47, Vladimir Kozlov wrote: > CC to runtime too since it has changes in Interpreter and affects our closed code. > > Hi Goetz, > > Please, set "Fix Version". > > And if it is JDK 9 you need FC Extension Request since you converted it to Enhancement: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > > Someone from Oracle have to sponsor it and do related closed code changes and testing. webrev.03 looks good to me. I did the necessary closed changes (review is pending) and also adapted some of the public code. Incremental webrev: http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ Full webrev: http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ I removed the PPC code because since 8u33, SE Embedded releases no longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM specific code into the closed sources. I adapted the copyright dates and refactored some related code. Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks for is_valid() which is false for fnoreg. We should check for 'as_FloatRegister(reg2) != fnoreg'. Tests are running. Best regards, Tobias [1] http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html [2] http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html > Thanks, > Vladimir > > On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> could someone please have a look at this issue? I recap the description >> below, and I also updated the webrev which would no more apply to >> hs-comp: >> >> c1_LIR.hpp defines a row of functions guarded by platform >> defines. This is bad style and hinders new platform ports. >> (I'm working on S390 aka Z :)) >> >> This change removes the majority of these defines. It introduces >> common headers, and moves implementations to c1_LIR_.cpp files. >> >> It guards single_softfp() and double_softfp() by __SOFTFP__. >> This is not used in any openJdk platform. I can not test this >> on the closed platforms ARM32 and PPC32. >> >> It removes the guard around the LIR_Address constructor. There >> is no point in guarding this code, verify() assures by >> assertions that it can not be misused. I also introduce a new >> constructor that leaves out the scale argument and introduce >> some usages on X86. >> >> This change also moves verify() to the new platform files. In the >> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >> of pd_verify(). Neither of these are used in openJdk. If this define >> is used in the closed ports pd_verify() must be renamed to verify(). >> >> The code that was previously guarded by ARM, ARM32 or PPC32 is >> moved to a properly guarded section in c1_LIR.cpp. Actually, >> it should be moved to according new files c1_LIR_.cpp in >> the closed ports. But this way the change should basically >> work for the closed ports. >> >> I added fnoreg on x86 to note down the code similarly on all >> platforms. >> >> I cleaned up a flag with a limited range on PPC_32. >> >> generate_stack_overflow_check() in templateInterpreterGenerator.hpp >> is defined with different parameters for the platforms. I added default >> parameters noreg so that the signature is the same for all platforms. >> >> Please review this change. I please need a sponsor. >> https://bugs.openjdk.java.net/browse/JDK-8160245 >> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ >> >> I built and tested this on linuxx86_64, solaris_sparc and >> the ppc platforms. >> >> Best regards, >> Goetz. >> >> From volker.simonis at gmail.com Tue Jul 12 12:48:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Jul 2016 14:48:38 +0200 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5783CEFF.1080206@oracle.com> References: <57839D8A.9050108@oracle.com> <5783C645.9010709@oracle.com> <5783CEFF.1080206@oracle.com> Message-ID: On Mon, Jul 11, 2016 at 6:53 PM, Alan Burlison wrote: > On 11/07/2016 17:41, Volker Simonis wrote: > >> you write that "for Solaris 11, _POSIX_PTHREAD_SEMANTICS enables the >> 'official' POSIX" semantics. Is this strictly true only for Solaris 11 >> or also for Solaris 10 already. I know this question is not directly >> related to your change which only applies to jdk9, but we may have to >> downport this change to older Solaris releases so if you have any >> experience with _POSIX_PTHREAD_SEMANTICS on Solaris 10 it would be >> good to know. > > > It is true for Solaris 10 and even Solaris 9. Thanks for the information. That's good for us :) > >> Besides that, could you please also fix the following bits: >> >> hotspot/src/os/solaris/vm/perfMemory_solaris.cpp >> - why do we need: >> >> +#if defined(SOLARIS) >> >> here. I think this file is always compiled with -DSOLARIS > > > I was just being (over) cautious, I'll make the change you suggest, thanks. > >> jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c >> jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c >> jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c >> - can you please use: >> #if defined(__solaris__) >> (as you did in ProcessHandleImpl_unix.c) instead of: >> #if defined(SOLARIS) > > > Sure. > >> In hotspot code it is more common to use our own platform defines from >> the command line whereas in the jdk repository we usually use the >> defualt system defines for the various platforms. > > > Ah right, I've seen a mix of styles and hadn't yet figured out the rule for > which to use where, thanks for the guidance :-) > > -- > Alan Burlison > -- From goetz.lindenmaier at sap.com Tue Jul 12 13:03:47 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Jul 2016 13:03:47 +0000 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <5784E3B8.40401@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> Message-ID: <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> Hi Tobias, thanks for looking at this change! Your additional edits look good. Thanks for spotting the problems. Unfortunately, we don't have an aarch machine. I also had problems with these asserts, as_FloatRegister(reg2) was not possible on ppc because it did not like the '-1'. But that's fixed already. Good to know there is no PPC32 any more. I always had to take care I don't break anything in this 'invisible team mate' on Power :) Do you want me to make a new webrev with your edits? I'm fine with the webrev you mailed around, though. I tested it to work on ppc, and I'll run it through our tests tonight. Best regards, Goetz. > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Dienstag, 12. Juli 2016 14:34 > To: Vladimir Kozlov ; Lindenmaier, Goetz > ; hotspot-compiler-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net runtime dev at openjdk.java.net> > Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > c1_LIR.hpp. > > Hi Goetz, > > On 06.07.2016 00:47, Vladimir Kozlov wrote: > > CC to runtime too since it has changes in Interpreter and affects our closed > code. > > > > Hi Goetz, > > > > Please, set "Fix Version". > > > > And if it is JDK 9 you need FC Extension Request since you converted it to > Enhancement: > > > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > > > > Someone from Oracle have to sponsor it and do related closed code > changes and testing. > > webrev.03 looks good to me. I did the necessary closed changes (review is > pending) and also adapted some of the public code. > > Incremental webrev: > http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ > > Full webrev: > http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ > > I removed the PPC code because since 8u33, SE Embedded releases no > longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM specific > code into the closed sources. I adapted the copyright dates and refactored > some related code. > > Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks for > is_valid() which is false for fnoreg. We should check for > 'as_FloatRegister(reg2) != fnoreg'. > > Tests are running. > > Best regards, > Tobias > > [1] http://www.oracle.com/technetwork/java/embedded/embedded- > se/downloads/index.html > [2] http://www.oracle.com/technetwork/java/javase/certconfig- > 2095354.html > > > Thanks, > > Vladimir > > > > On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: > >> Hi, > >> > >> could someone please have a look at this issue? I recap the description > >> below, and I also updated the webrev which would no more apply to > >> hs-comp: > >> > >> c1_LIR.hpp defines a row of functions guarded by platform > >> defines. This is bad style and hinders new platform ports. > >> (I'm working on S390 aka Z :)) > >> > >> This change removes the majority of these defines. It introduces > >> common headers, and moves implementations to c1_LIR_.cpp files. > >> > >> It guards single_softfp() and double_softfp() by __SOFTFP__. > >> This is not used in any openJdk platform. I can not test this > >> on the closed platforms ARM32 and PPC32. > >> > >> It removes the guard around the LIR_Address constructor. There > >> is no point in guarding this code, verify() assures by > >> assertions that it can not be misused. I also introduce a new > >> constructor that leaves out the scale argument and introduce > >> some usages on X86. > >> > >> This change also moves verify() to the new platform files. In the > >> header, LIR_ADDRESS_PD_VERIFY was used to guard usage > >> of pd_verify(). Neither of these are used in openJdk. If this define > >> is used in the closed ports pd_verify() must be renamed to verify(). > >> > >> The code that was previously guarded by ARM, ARM32 or PPC32 is > >> moved to a properly guarded section in c1_LIR.cpp. Actually, > >> it should be moved to according new files c1_LIR_.cpp in > >> the closed ports. But this way the change should basically > >> work for the closed ports. > >> > >> I added fnoreg on x86 to note down the code similarly on all > >> platforms. > >> > >> I cleaned up a flag with a limited range on PPC_32. > >> > >> generate_stack_overflow_check() in templateInterpreterGenerator.hpp > >> is defined with different parameters for the platforms. I added default > >> parameters noreg so that the signature is the same for all platforms. > >> > >> Please review this change. I please need a sponsor. > >> https://bugs.openjdk.java.net/browse/JDK-8160245 > >> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ > >> > >> I built and tested this on linuxx86_64, solaris_sparc and > >> the ppc platforms. > >> > >> Best regards, > >> Goetz. > >> > >> From tobias.hartmann at oracle.com Tue Jul 12 13:07:06 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jul 2016 15:07:06 +0200 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> Message-ID: <5784EB7A.3000608@oracle.com> Hi Goetz, On 12.07.2016 15:03, Lindenmaier, Goetz wrote: > Hi Tobias, > > thanks for looking at this change! Your additional edits look good. > Thanks for spotting the problems. Unfortunately, we don't have > an aarch machine. Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on SPARC. > I also had problems with these asserts, as_FloatRegister(reg2) > was not possible on ppc because it did not like the '-1'. But that's > fixed already. Yes, I noticed that. > Good to know there is no PPC32 any more. I always had to take > care I don't break anything in this 'invisible team mate' on Power :) > > Do you want me to make a new webrev with your edits? I'm > fine with the webrev you mailed around, though. I tested it to > work on ppc, and I'll run it through our tests tonight. You don't have to create a new webrev. If all testing passed and the other reviewers agree with the latest webrev, you can send me a changeset and I'll push it. Best regards, Tobias > Best regards, > Goetz. > >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Dienstag, 12. Juli 2016 14:34 >> To: Vladimir Kozlov ; Lindenmaier, Goetz >> ; hotspot-compiler-dev at openjdk.java.net >> Cc: hotspot-runtime-dev at openjdk.java.net runtime > dev at openjdk.java.net> >> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >> c1_LIR.hpp. >> >> Hi Goetz, >> >> On 06.07.2016 00:47, Vladimir Kozlov wrote: >>> CC to runtime too since it has changes in Interpreter and affects our closed >> code. >>> >>> Hi Goetz, >>> >>> Please, set "Fix Version". >>> >>> And if it is JDK 9 you need FC Extension Request since you converted it to >> Enhancement: >>> >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html >>> >>> Someone from Oracle have to sponsor it and do related closed code >> changes and testing. >> >> webrev.03 looks good to me. I did the necessary closed changes (review is >> pending) and also adapted some of the public code. >> >> Incremental webrev: >> http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ >> >> Full webrev: >> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >> >> I removed the PPC code because since 8u33, SE Embedded releases no >> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM specific >> code into the closed sources. I adapted the copyright dates and refactored >> some related code. >> >> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks for >> is_valid() which is false for fnoreg. We should check for >> 'as_FloatRegister(reg2) != fnoreg'. >> >> Tests are running. >> >> Best regards, >> Tobias >> >> [1] http://www.oracle.com/technetwork/java/embedded/embedded- >> se/downloads/index.html >> [2] http://www.oracle.com/technetwork/java/javase/certconfig- >> 2095354.html >> >>> Thanks, >>> Vladimir >>> >>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> could someone please have a look at this issue? I recap the description >>>> below, and I also updated the webrev which would no more apply to >>>> hs-comp: >>>> >>>> c1_LIR.hpp defines a row of functions guarded by platform >>>> defines. This is bad style and hinders new platform ports. >>>> (I'm working on S390 aka Z :)) >>>> >>>> This change removes the majority of these defines. It introduces >>>> common headers, and moves implementations to c1_LIR_.cpp files. >>>> >>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>> This is not used in any openJdk platform. I can not test this >>>> on the closed platforms ARM32 and PPC32. >>>> >>>> It removes the guard around the LIR_Address constructor. There >>>> is no point in guarding this code, verify() assures by >>>> assertions that it can not be misused. I also introduce a new >>>> constructor that leaves out the scale argument and introduce >>>> some usages on X86. >>>> >>>> This change also moves verify() to the new platform files. In the >>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>> >>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>> it should be moved to according new files c1_LIR_.cpp in >>>> the closed ports. But this way the change should basically >>>> work for the closed ports. >>>> >>>> I added fnoreg on x86 to note down the code similarly on all >>>> platforms. >>>> >>>> I cleaned up a flag with a limited range on PPC_32. >>>> >>>> generate_stack_overflow_check() in templateInterpreterGenerator.hpp >>>> is defined with different parameters for the platforms. I added default >>>> parameters noreg so that the signature is the same for all platforms. >>>> >>>> Please review this change. I please need a sponsor. >>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ >>>> >>>> I built and tested this on linuxx86_64, solaris_sparc and >>>> the ppc platforms. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> From ioi.lam at oracle.com Tue Jul 12 13:29:06 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 12 Jul 2016 06:29:06 -0700 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> References: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> Message-ID: <5784F0A2.4010005@oracle.com> Hi Gerard, The changes look good. A small nit here: 826 tty->print("%4d: hits %5.2f%c", ...., '%'); This should be changed to 826 tty->print("%4d: hits %5.2f%%", ...); Also in hashtable.hpp: 129 long _hits; Is there any reason to not use 'int'? _lookup_count is an 'int'. Also, the terminology used by the VM is -- we have 1009 'buckets', and each bucket contains zero or more 'entries' in a link list. So the help message should be something like: 1st number: the bucket index 2nd number: the entry's index within this bucket 3rd number: the hit percentage of this entry 4th number: the hash index of this entry Thanks - Ioi On 7/11/16 10:25 AM, Gerard Ziemski wrote: > hi all, > > Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. > > Currently all we print is just the warning's 1st line below, but with this fix we show the following: > > ----------------------------- > Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 > Java system dictionary (table_size=1009, classes=484) > ^ indicates that initiating loader is different from defining loader > 1st number shows bucket index > 2nd number shows chain index within a bucket > 3rd number shows hit percentage of the bucket > 4th number shows hash index > 0: > 1: > 2: > 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader > 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader > 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader > 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader > 5: > . > . > . > 1003: > 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader > 1005: > 1006: > 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader > 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader > > Top 16 buckets: > 546: hits 2.76% > 183: hits 0.87% > 969: hits 2.37%s > 281: hits 0.95% > 957: hits 1.73% > 571: hits 16.67% > 221: hits 0.98% > 505: hits 0.84% > 727: hits 1.28% > 414: hits 1.73% > 569: hits 4.89% > 245: hits 0.89% > 253: hits 1.34% > 135: hits 0.95% > 457: hits 0.87% > 348: hits 1.23% > > Protection domain cache table (table_size=2017, classes=1) > entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 > ----------------------------- > > We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. > > In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. > > open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 > bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > > Passes JPRT hotspot. > > > cheers > From harold.seigel at oracle.com Tue Jul 12 13:57:06 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 12 Jul 2016 09:57:06 -0400 Subject: RFR (8u): 8042660: vm/mlvm/anonloader/stress/byteMutation failed with: assert(index >=0 && index < _length) failed: symbol index overflow In-Reply-To: References: Message-ID: <4893770d-489e-9c44-b8a3-bac9b808e159@oracle.com> Hi Poonam, These changes look good. Thanks, Harold On 7/11/2016 3:28 PM, Poonam Bajaj Parhar wrote: > Hello, > > Please review these changes that backport the fix of '8042660: > vm/mlvm/anonloader/stress/byteMutation failed with: assert(index >=0 > && index < _length) failed: symbol index overflow' to 8u. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8042660 > Webrev:http://cr.openjdk.java.net/~poonam/8042660/webrev.8u.00/ > Testing: > - JPRT > - Tested the testcase BadNameAndType with the fastdebug build of the > fixed 8u JDK. > > Thanks, > Poonam > > From serguei.spitsyn at oracle.com Tue Jul 12 15:37:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Jul 2016 08:37:17 -0700 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> Message-ID: <57850EAD.7060203@oracle.com> Hi Dmitry, The fix and test look good. Thanks, Serguei On 7/11/16 07:06, Lindenmaier, Goetz wrote: > Hi Dmitry, > > thanks fort he fixed, looks good now. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >> Sent: Montag, 11. Juli 2016 15:51 >> To: Coleen Phillimore ; serviceability- >> dev at openjdk.java.net; hotspot-runtime-dev > dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net; >> Lindenmaier, Goetz >> Subject: Re: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires >> assert(_exception_caught == false) failed: _exception_caught is out of phase >> >> Everybody, >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/ >> >> Testcase added. Goetz's concerns addressed. >> >> -Dmitry >> >> >> On 2016-07-11 16:35, Coleen Phillimore wrote: >>> Adding hotspot-compiler-dev since the change is in opto/runtime.cpp >>> >>> Coleen >>> >>> On 7/11/16 4:22 AM, Dmitry Samersoff wrote: >>>> PING ... >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires >>>> assert(_exception_caught == false) failed: _exception_caught is out of >>>> phase >>>> Date: Wed, 6 Jul 2016 19:24:15 +0300 >>>> From: Dmitry Samersoff >>>> To: serviceability-dev at openjdk.java.net >>>> >>>> >>>> Everybody, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ >>>> >>>> All credentials belongs to Richard Reingruber, see mail thread (below) >>>> for details. >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015- >> August/019613.html >>>> >>>> >>>> -Dmitry >>>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From gerard.ziemski at oracle.com Wed Jul 13 16:49:02 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 13 Jul 2016 11:49:02 -0500 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <3D8517A0-A501-4858-818B-EAF511224E01@twitter.com> References: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> <3D8517A0-A501-4858-818B-EAF511224E01@twitter.com> Message-ID: Thank you for the review. I made the change and will be posting 2nd webrev shortly. cheers > On Jul 11, 2016, at 7:24 PM, Christian Thalinger wrote: > > Is this temporary or do you want to keep this code? If you want to keep it debug_only should be upper-case DEBUG_ONLY. > >> On Jul 11, 2016, at 7:25 AM, Gerard Ziemski wrote: >> >> hi all, >> >> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >> >> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >> >> ----------------------------- >> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >> Java system dictionary (table_size=1009, classes=484) >> ^ indicates that initiating loader is different from defining loader >> 1st number shows bucket index >> 2nd number shows chain index within a bucket >> 3rd number shows hit percentage of the bucket >> 4th number shows hash index >> 0: >> 1: >> 2: >> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >> 5: >> . >> . >> . >> 1003: >> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >> 1005: >> 1006: >> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >> >> Top 16 buckets: >> 546: hits 2.76% >> 183: hits 0.87% >> 969: hits 2.37%s >> 281: hits 0.95% >> 957: hits 1.73% >> 571: hits 16.67% >> 221: hits 0.98% >> 505: hits 0.84% >> 727: hits 1.28% >> 414: hits 1.73% >> 569: hits 4.89% >> 245: hits 0.89% >> 253: hits 1.34% >> 135: hits 0.95% >> 457: hits 0.87% >> 348: hits 1.23% >> >> Protection domain cache table (table_size=2017, classes=1) >> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >> ----------------------------- >> >> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >> >> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >> >> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> Passes JPRT hotspot. >> >> >> cheers >> > From gerard.ziemski at oracle.com Wed Jul 13 16:49:30 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 13 Jul 2016 11:49:30 -0500 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <7bd93661-b50a-ab4c-2641-b81e5ffbcf9c@oracle.com> References: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> <7bd93661-b50a-ab4c-2641-b81e5ffbcf9c@oracle.com> Message-ID: Thank you for the review. I made the change and will be posting 2nd webrev shortly. cheers > On Jul 11, 2016, at 10:44 PM, David Holmes wrote: > > Hi Gerard, > > Please include the bug number in the RFR subject - thanks. > > Adding the additional diagnostic info seems okay for debug builds. > > Two style nits with src/share/vm/classfile/dictionary.cpp > > 1. As Christian mentioned DEBUG_ONLY is preferred, but debug_only is presently used. I would not be adverse to going a global replace in this file in this case. > > 2. Please ensure there are spaces around operators, particularly in for loops e.g.: > > - good: 757 for (int i = 0; i < table_size(); i++) { > - bad: 753 for (int i=0; i > Thanks, > David > > On 12/07/2016 3:25 AM, Gerard Ziemski wrote: >> hi all, >> >> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >> >> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >> >> ----------------------------- >> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >> Java system dictionary (table_size=1009, classes=484) >> ^ indicates that initiating loader is different from defining loader >> 1st number shows bucket index >> 2nd number shows chain index within a bucket >> 3rd number shows hit percentage of the bucket >> 4th number shows hash index >> 0: >> 1: >> 2: >> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >> 5: >> . >> . >> . >> 1003: >> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >> 1005: >> 1006: >> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >> >> Top 16 buckets: >> 546: hits 2.76% >> 183: hits 0.87% >> 969: hits 2.37%s >> 281: hits 0.95% >> 957: hits 1.73% >> 571: hits 16.67% >> 221: hits 0.98% >> 505: hits 0.84% >> 727: hits 1.28% >> 414: hits 1.73% >> 569: hits 4.89% >> 245: hits 0.89% >> 253: hits 1.34% >> 135: hits 0.95% >> 457: hits 0.87% >> 348: hits 1.23% >> >> Protection domain cache table (table_size=2017, classes=1) >> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >> ----------------------------- >> >> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >> >> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >> >> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> Passes JPRT hotspot. >> >> >> cheers >> From Alan.Burlison at oracle.com Wed Jul 13 16:50:47 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 13 Jul 2016 17:50:47 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <57839D8A.9050108@oracle.com> References: <57839D8A.9050108@oracle.com> Message-ID: <57867167.7020001@oracle.com> On 11/07/2016 14:22, Alan Burlison wrote: > Hi, I'd like to ask for reviews for: > > JDK-8160997 Solaris: deprecated and interfaces should be > replaced I've addressed all the review comments, the updated webrev is available at: http://cr.openjdk.java.net/~dcubed/for_alanbur/8160997-webrev/1-jdk9-hs-all/ Thanks, -- Alan Burlison -- From gerard.ziemski at oracle.com Wed Jul 13 16:52:41 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 13 Jul 2016 11:52:41 -0500 Subject: RFR (M): [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <5784F0A2.4010005@oracle.com> References: <27657AC0-2A47-4A9A-9C9F-1C17698E0E62@oracle.com> <5784F0A2.4010005@oracle.com> Message-ID: <38ED7693-203A-4794-9ABE-A380F9869C90@oracle.com> Thank you for the review. I made the changes and will be posting 2nd webrev shortly. cheers > On Jul 12, 2016, at 8:29 AM, Ioi Lam wrote: > > Hi Gerard, > > The changes look good. A small nit here: > > 826 tty->print("%4d: hits %5.2f%c", ...., '%'); > > This should be changed to > > 826 tty->print("%4d: hits %5.2f%%", ...); > > Also in hashtable.hpp: > > 129 long _hits; > > Is there any reason to not use 'int'? _lookup_count is an 'int'. > > Also, the terminology used by the VM is -- we have 1009 'buckets', and each bucket contains zero or more 'entries' in a link list. > > So the help message should be something like: > > 1st number: the bucket index > 2nd number: the entry's index within this bucket > 3rd number: the hit percentage of this entry > 4th number: the hash index of this entry > > Thanks > - Ioi > > > > On 7/11/16 10:25 AM, Gerard Ziemski wrote: >> hi all, >> >> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >> >> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >> >> ----------------------------- >> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >> Java system dictionary (table_size=1009, classes=484) >> ^ indicates that initiating loader is different from defining loader >> 1st number shows bucket index >> 2nd number shows chain index within a bucket >> 3rd number shows hit percentage of the bucket >> 4th number shows hash index >> 0: >> 1: >> 2: >> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >> 5: >> . >> . >> . >> 1003: >> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >> 1005: >> 1006: >> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >> >> Top 16 buckets: >> 546: hits 2.76% >> 183: hits 0.87% >> 969: hits 2.37%s >> 281: hits 0.95% >> 957: hits 1.73% >> 571: hits 16.67% >> 221: hits 0.98% >> 505: hits 0.84% >> 727: hits 1.28% >> 414: hits 1.73% >> 569: hits 4.89% >> 245: hits 0.89% >> 253: hits 1.34% >> 135: hits 0.95% >> 457: hits 0.87% >> 348: hits 1.23% >> >> Protection domain cache table (table_size=2017, classes=1) >> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >> ----------------------------- >> >> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >> >> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >> >> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> Passes JPRT hotspot. >> >> >> cheers >> > From daniel.daugherty at oracle.com Wed Jul 13 17:14:58 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Jul 2016 11:14:58 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <57867167.7020001@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> Message-ID: On 7/13/16 10:50 AM, Alan Burlison wrote: > On 11/07/2016 14:22, Alan Burlison wrote: > >> Hi, I'd like to ask for reviews for: >> >> JDK-8160997 Solaris: deprecated and interfaces should be >> replaced > > I've addressed all the review comments, the updated webrev is > available at: > > http://cr.openjdk.java.net/~dcubed/for_alanbur/8160997-webrev/1-jdk9-hs-all/ > hotspot/src/os/solaris/vm/os_solaris.cpp No comments. hotspot/src/os/solaris/vm/perfMemory_solaris.cpp No comments. hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp No comments. hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp No comments. jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c No comments. jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c No comments. jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c No comments (nice catch on the duplicate 'jclass cls' decl). jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c No comments. Thumbs up. Dan > > Thanks, > From gerard.ziemski at oracle.com Wed Jul 13 19:31:01 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 13 Jul 2016 14:31:01 -0500 Subject: RFR (M): JDK-8138760: [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 Message-ID: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> hi all, Here is a webrev 2, which incorporates the following feedback: #1. Changed ?debug_only" to ?DEBUG_ONLY" (Christian, David), including all instances in the files where I used the macros #2. Fixed the ?for? loops (David) #3. Using ?unsigned? for hit counter instead of "long" (Ioi) #4. Changed the help message (Ioi) #5. Changed how I print ?%? (Ioi) webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev2 bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. > > Currently all we print is just the warning's 1st line below, but with this fix we show the following: > > ----------------------------- > Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 > Java system dictionary (table_size=1009, classes=484) > ^ indicates that initiating loader is different from defining loader > 1st number shows bucket index > 2nd number shows chain index within a bucket > 3rd number shows hit percentage of the bucket > 4th number shows hash index > 0: > 1: > 2: > 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader > 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader > 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader > 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader > 5: > . > . > . > 1003: > 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader > 1005: > 1006: > 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader > 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader > > Top 16 buckets: > 546: hits 2.76% > 183: hits 0.87% > 969: hits 2.37%s > 281: hits 0.95% > 957: hits 1.73% > 571: hits 16.67% > 221: hits 0.98% > 505: hits 0.84% > 727: hits 1.28% > 414: hits 1.73% > 569: hits 4.89% > 245: hits 0.89% > 253: hits 1.34% > 135: hits 0.95% > 457: hits 0.87% > 348: hits 1.23% > > Protection domain cache table (table_size=2017, classes=1) > entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 > ----------------------------- > > We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. > > In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. > > open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 > closed webrev: http://javaweb.us.oracle.com/~gziemski/webrevs/8138760_rev1 > bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > > Passes JPRT hotspot. cheers From calvin.cheung at oracle.com Wed Jul 13 21:33:14 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 13 Jul 2016 14:33:14 -0700 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp Message-ID: <5786B39A.6050805@oracle.com> Please review this small fix for adding the missing newline char in the exception messages in diagnosticArgument.cpp. If the vm_exit_during_initialization() is called after the THROW_MSG() in diagnosticArgument.cpp, the error looks like the following: java.lang.IllegalArgumentException: Integer parsing error nanotime value: syntax errorError occurred during initialization of VM Failed to start tracing backend. After the fix, it becomes: java.lang.IllegalArgumentException: Integer parsing error nanotime value: syntax error Error occurred during initialization of VM Failed to start tracing backend. bug: https://bugs.openjdk.java.net/browse/JDK-8159901 (it is marked confidential) webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ The fix passed JPRT and related tests in the closed repo. thanks, Calvin From frederic.parain at oracle.com Wed Jul 13 21:07:25 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 13 Jul 2016 17:07:25 -0400 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp In-Reply-To: <5786B39A.6050805@oracle.com> References: <5786B39A.6050805@oracle.com> Message-ID: <5786AD8D.2000901@oracle.com> Fix looks good to me. Thank you fixing this. Fred On 13/07/2016 17:33, Calvin Cheung wrote: > > Please review this small fix for adding the missing newline char in the > exception messages in diagnosticArgument.cpp. > > If the vm_exit_during_initialization() is called after the THROW_MSG() > in diagnosticArgument.cpp, the error looks like the following: > java.lang.IllegalArgumentException: Integer parsing error nanotime > value: syntax errorError occurred during initialization of VM > Failed to start tracing backend. > > After the fix, it becomes: > java.lang.IllegalArgumentException: Integer parsing error nanotime > value: syntax error > Error occurred during initialization of VM > Failed to start tracing backend. > > bug: https://bugs.openjdk.java.net/browse/JDK-8159901 > (it is marked confidential) > > webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ > > The fix passed JPRT and related tests in the closed repo. > > thanks, > Calvin > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From calvin.cheung at oracle.com Wed Jul 13 21:58:28 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 13 Jul 2016 14:58:28 -0700 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp In-Reply-To: <5786AD8D.2000901@oracle.com> References: <5786B39A.6050805@oracle.com> <5786AD8D.2000901@oracle.com> Message-ID: <5786B984.1050502@oracle.com> Fred, Thanks for your quick review. Calvin On 7/13/16, 2:07 PM, Frederic Parain wrote: > Fix looks good to me. > > Thank you fixing this. > > Fred > > On 13/07/2016 17:33, Calvin Cheung wrote: >> >> Please review this small fix for adding the missing newline char in the >> exception messages in diagnosticArgument.cpp. >> >> If the vm_exit_during_initialization() is called after the THROW_MSG() >> in diagnosticArgument.cpp, the error looks like the following: >> java.lang.IllegalArgumentException: Integer parsing error nanotime >> value: syntax errorError occurred during initialization of VM >> Failed to start tracing backend. >> >> After the fix, it becomes: >> java.lang.IllegalArgumentException: Integer parsing error nanotime >> value: syntax error >> Error occurred during initialization of VM >> Failed to start tracing backend. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159901 >> (it is marked confidential) >> >> webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ >> >> The fix passed JPRT and related tests in the closed repo. >> >> thanks, >> Calvin >> > From erik.gahlin at oracle.com Wed Jul 13 22:01:53 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 14 Jul 2016 00:01:53 +0200 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp In-Reply-To: <5786B39A.6050805@oracle.com> References: <5786B39A.6050805@oracle.com> Message-ID: <5786BA51.3040807@oracle.com> Looks good. Erik On 2016-07-13 23:33, Calvin Cheung wrote: > > Please review this small fix for adding the missing newline char in > the exception messages in diagnosticArgument.cpp. > > If the vm_exit_during_initialization() is called after the THROW_MSG() > in diagnosticArgument.cpp, the error looks like the following: > java.lang.IllegalArgumentException: Integer parsing error nanotime > value: syntax errorError occurred during initialization of VM > Failed to start tracing backend. > > After the fix, it becomes: > java.lang.IllegalArgumentException: Integer parsing error nanotime > value: syntax error > Error occurred during initialization of VM > Failed to start tracing backend. > > bug: https://bugs.openjdk.java.net/browse/JDK-8159901 > (it is marked confidential) > > webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ > > The fix passed JPRT and related tests in the closed repo. > > thanks, > Calvin > From calvin.cheung at oracle.com Wed Jul 13 22:12:24 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 13 Jul 2016 15:12:24 -0700 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp In-Reply-To: <5786BA51.3040807@oracle.com> References: <5786B39A.6050805@oracle.com> <5786BA51.3040807@oracle.com> Message-ID: <5786BCC8.7060201@oracle.com> Thank you - Erik. Calvin On 7/13/16, 3:01 PM, Erik Gahlin wrote: > Looks good. > > Erik > > On 2016-07-13 23:33, Calvin Cheung wrote: >> >> Please review this small fix for adding the missing newline char in >> the exception messages in diagnosticArgument.cpp. >> >> If the vm_exit_during_initialization() is called after the >> THROW_MSG() in diagnosticArgument.cpp, the error looks like the >> following: >> java.lang.IllegalArgumentException: Integer parsing error nanotime >> value: syntax errorError occurred during initialization of VM >> Failed to start tracing backend. >> >> After the fix, it becomes: >> java.lang.IllegalArgumentException: Integer parsing error nanotime >> value: syntax error >> Error occurred during initialization of VM >> Failed to start tracing backend. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159901 >> (it is marked confidential) >> >> webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ >> >> The fix passed JPRT and related tests in the closed repo. >> >> thanks, >> Calvin >> > From jiangli.zhou at oracle.com Thu Jul 14 00:06:15 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 13 Jul 2016 17:06:15 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> Message-ID: Here is the updated webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). Agent specified via command line: With -Xshare:on, report error and exit. Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. With -Xshare:auto, disallow loading shared class If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). Agent is attached: With -Xshare:on and -Xshare:auto Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. Thanks, Jiangli > On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: > > Hi Ioi, > >> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >> >> Hi Jiangli, >> >> I agree what what Karen has said. >> >> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >> >> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. > > Agreed. > >> >> Also, maybe this check can also be removed? >> >> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >> >> Since the same check is already done in the "inner" load_shared_class() method. > > I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. > > Thanks, > Jiangli > >> >> Thanks >> - Ioi >> >> >> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>> Hi Karen, >>> >>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>> >>> Thanks, >>> Jiangli >>> >>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>> >>>> Jiangli, >>>> >>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>> >>>> I agree with not quitting the vm on agent attach. >>>> I actually think we also want the agent attach to succeed - see below. >>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>> >>>>> (Adding serviceability-dev at openjdk.java.net) >>>>> >>>>> Hi Jiangli, >>>>> >>>>> I think the two blocks of >>>>> >>>>> if (RequireSharedSpaces) { >>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>> vm_exit(1); >>>>> } >>>>> >>>>> should be removed. >>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>> but no forcing of using the shared spaces if there is an agent. >>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>> Totally agree - we should not quit the VM. >>>> >>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>> >>>>> jvmtiError >>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>> >>>>> ... >>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>> + } >>>>> record_class_file_load_hook_enabled(); >>>>> } >>>>> ? >>>>> } >>>>> >>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>> Thanks >>>>> - Ioi >>>> Jiangli: >>>> >>>> Minor code review comments: >>>> >>>> metaspace.cpp line 3181: CFHL-> CFLH >>>> >>>> metaspace.cpp: >>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>> >>>> thanks, >>>> Karen >>>> >>>>> >>>>> >>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>> bug: JDK-8141341 >>>>>> >>>>>> With -Xshare:on >>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>> >>>>>> With -Xshare:auto >>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>> >>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> >> > From david.holmes at oracle.com Thu Jul 14 00:37:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2016 10:37:06 +1000 Subject: RFR (M): JDK-8138760: [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> References: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> Message-ID: Looks good! Thanks Gerard. David On 14/07/2016 5:31 AM, Gerard Ziemski wrote: > hi all, > > Here is a webrev 2, which incorporates the following feedback: > > #1. Changed ?debug_only" to ?DEBUG_ONLY" (Christian, David), including all instances in the files where I used the macros > > #2. Fixed the ?for? loops (David) > > #3. Using ?unsigned? for hit counter instead of "long" (Ioi) > > #4. Changed the help message (Ioi) > > #5. Changed how I print ?%? (Ioi) > > webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev2 > bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > > >> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >> >> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >> >> ----------------------------- >> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >> Java system dictionary (table_size=1009, classes=484) >> ^ indicates that initiating loader is different from defining loader >> 1st number shows bucket index >> 2nd number shows chain index within a bucket >> 3rd number shows hit percentage of the bucket >> 4th number shows hash index >> 0: >> 1: >> 2: >> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >> 5: >> . >> . >> . >> 1003: >> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >> 1005: >> 1006: >> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >> >> Top 16 buckets: >> 546: hits 2.76% >> 183: hits 0.87% >> 969: hits 2.37%s >> 281: hits 0.95% >> 957: hits 1.73% >> 571: hits 16.67% >> 221: hits 0.98% >> 505: hits 0.84% >> 727: hits 1.28% >> 414: hits 1.73% >> 569: hits 4.89% >> 245: hits 0.89% >> 253: hits 1.34% >> 135: hits 0.95% >> 457: hits 0.87% >> 348: hits 1.23% >> >> Protection domain cache table (table_size=2017, classes=1) >> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >> ----------------------------- >> >> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >> >> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >> >> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >> closed webrev: http://javaweb.us.oracle.com/~gziemski/webrevs/8138760_rev1 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> Passes JPRT hotspot. > > cheers > From ioi.lam at oracle.com Thu Jul 14 01:02:01 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 13 Jul 2016 18:02:01 -0700 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp In-Reply-To: <5786B39A.6050805@oracle.com> References: <5786B39A.6050805@oracle.com> Message-ID: <5786E489.5060202@oracle.com> Looks good. Thanks Calvin! - Ioi On 7/13/16 2:33 PM, Calvin Cheung wrote: > > Please review this small fix for adding the missing newline char in > the exception messages in diagnosticArgument.cpp. > > If the vm_exit_during_initialization() is called after the THROW_MSG() > in diagnosticArgument.cpp, the error looks like the following: > java.lang.IllegalArgumentException: Integer parsing error nanotime > value: syntax errorError occurred during initialization of VM > Failed to start tracing backend. > > After the fix, it becomes: > java.lang.IllegalArgumentException: Integer parsing error nanotime > value: syntax error > Error occurred during initialization of VM > Failed to start tracing backend. > > bug: https://bugs.openjdk.java.net/browse/JDK-8159901 > (it is marked confidential) > > webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ > > The fix passed JPRT and related tests in the closed repo. > > thanks, > Calvin > From calvin.cheung at oracle.com Thu Jul 14 01:11:48 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 13 Jul 2016 18:11:48 -0700 Subject: RFR(XS): 8159901: missing newline char in the exception messages in diagnosticArgument.cpp In-Reply-To: <5786E489.5060202@oracle.com> References: <5786B39A.6050805@oracle.com> <5786E489.5060202@oracle.com> Message-ID: <5786E6D4.60702@oracle.com> Thanks - Ioi. Calvin On 7/13/16, 6:02 PM, Ioi Lam wrote: > Looks good. Thanks Calvin! > > - Ioi > > On 7/13/16 2:33 PM, Calvin Cheung wrote: >> >> Please review this small fix for adding the missing newline char in >> the exception messages in diagnosticArgument.cpp. >> >> If the vm_exit_during_initialization() is called after the >> THROW_MSG() in diagnosticArgument.cpp, the error looks like the >> following: >> java.lang.IllegalArgumentException: Integer parsing error nanotime >> value: syntax errorError occurred during initialization of VM >> Failed to start tracing backend. >> >> After the fix, it becomes: >> java.lang.IllegalArgumentException: Integer parsing error nanotime >> value: syntax error >> Error occurred during initialization of VM >> Failed to start tracing backend. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159901 >> (it is marked confidential) >> >> webrev: http://cr.openjdk.java.net/~ccheung/8159901/webrev.00/ >> >> The fix passed JPRT and related tests in the closed repo. >> >> thanks, >> Calvin >> > From david.holmes at oracle.com Thu Jul 14 01:20:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2016 11:20:59 +1000 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <57867167.7020001@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> Message-ID: <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> Hi Alan, Thanks for noticing this and cleaning it up. On 14/07/2016 2:50 AM, Alan Burlison wrote: > On 11/07/2016 14:22, Alan Burlison wrote: > >> Hi, I'd like to ask for reviews for: >> >> JDK-8160997 Solaris: deprecated and interfaces should be >> replaced > > I've addressed all the review comments, the updated webrev is available at: > > http://cr.openjdk.java.net/~dcubed/for_alanbur/8160997-webrev/1-jdk9-hs-all/ One query: if pwd.h is not the last file included don't we need to undef _POSIX_PTHREAD_SEMANTICS again to ensure no other included definitions are affected? If we don't need to do that then I wonder whether _POSIX_PTHREAD_SEMANTICS should not simply be set via the build system for all compilations? Thanks, David > > Thanks, > From ioi.lam at oracle.com Thu Jul 14 02:57:46 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 13 Jul 2016 19:57:46 -0700 Subject: RFR (M): JDK-8138760: [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> References: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> Message-ID: <5786FFAA.1060502@oracle.com> Hi Gerard, Looks good. Thanks - Ioi On 7/13/16 12:31 PM, Gerard Ziemski wrote: > hi all, > > Here is a webrev 2, which incorporates the following feedback: > > #1. Changed ?debug_only" to ?DEBUG_ONLY" (Christian, David), including all instances in the files where I used the macros > > #2. Fixed the ?for? loops (David) > > #3. Using ?unsigned? for hit counter instead of "long" (Ioi) > > #4. Changed the help message (Ioi) > > #5. Changed how I print ?%? (Ioi) > > webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev2 > bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 > > >> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >> >> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >> >> ----------------------------- >> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >> Java system dictionary (table_size=1009, classes=484) >> ^ indicates that initiating loader is different from defining loader >> 1st number shows bucket index >> 2nd number shows chain index within a bucket >> 3rd number shows hit percentage of the bucket >> 4th number shows hash index >> 0: >> 1: >> 2: >> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >> 5: >> . >> . >> . >> 1003: >> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >> 1005: >> 1006: >> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >> >> Top 16 buckets: >> 546: hits 2.76% >> 183: hits 0.87% >> 969: hits 2.37%s >> 281: hits 0.95% >> 957: hits 1.73% >> 571: hits 16.67% >> 221: hits 0.98% >> 505: hits 0.84% >> 727: hits 1.28% >> 414: hits 1.73% >> 569: hits 4.89% >> 245: hits 0.89% >> 253: hits 1.34% >> 135: hits 0.95% >> 457: hits 0.87% >> 348: hits 1.23% >> >> Protection domain cache table (table_size=2017, classes=1) >> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >> ----------------------------- >> >> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >> >> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >> >> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >> closed webrev: http://javaweb.us.oracle.com/~gziemski/webrevs/8138760_rev1 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> Passes JPRT hotspot. > cheers > From david.holmes at oracle.com Thu Jul 14 04:26:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2016 14:26:14 +1000 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED Message-ID: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> The bug report for this is confidential but quite simply all of the little tweaks and knobs we added to the open build and source files to support the Java SE Embedded product no longer need to be there for JDK 9. A lot of this has already been addressed in relation to other changes (eg. new hotspot build), but this cleans out the rest. webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ There are related JDK changes being handled in a separate review thread. If you like you can see them all: http://cr.openjdk.java.net/~dholmes/8140723/ Thanks, David From tobias.hartmann at oracle.com Thu Jul 14 05:53:58 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jul 2016 07:53:58 +0200 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <5784EB7A.3000608@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> <5784EB7A.3000608@oracle.com> Message-ID: <578728F6.2060306@oracle.com> Hi, all tests passed. If everyone's fine with the latest webrev, I'll push this tomorrow: http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ Goetz, could you please send me a changeset? Thanks, Tobias On 12.07.2016 15:07, Tobias Hartmann wrote: > Hi Goetz, > > On 12.07.2016 15:03, Lindenmaier, Goetz wrote: >> Hi Tobias, >> >> thanks for looking at this change! Your additional edits look good. >> Thanks for spotting the problems. Unfortunately, we don't have >> an aarch machine. > > Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on SPARC. > >> I also had problems with these asserts, as_FloatRegister(reg2) >> was not possible on ppc because it did not like the '-1'. But that's >> fixed already. > > Yes, I noticed that. > >> Good to know there is no PPC32 any more. I always had to take >> care I don't break anything in this 'invisible team mate' on Power :) >> >> Do you want me to make a new webrev with your edits? I'm >> fine with the webrev you mailed around, though. I tested it to >> work on ppc, and I'll run it through our tests tonight. > > You don't have to create a new webrev. If all testing passed and the other reviewers agree with the latest webrev, you can send me a changeset and I'll push it. > > Best regards, > Tobias > >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>> Sent: Dienstag, 12. Juli 2016 14:34 >>> To: Vladimir Kozlov ; Lindenmaier, Goetz >>> ; hotspot-compiler-dev at openjdk.java.net >>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >> dev at openjdk.java.net> >>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>> c1_LIR.hpp. >>> >>> Hi Goetz, >>> >>> On 06.07.2016 00:47, Vladimir Kozlov wrote: >>>> CC to runtime too since it has changes in Interpreter and affects our closed >>> code. >>>> >>>> Hi Goetz, >>>> >>>> Please, set "Fix Version". >>>> >>>> And if it is JDK 9 you need FC Extension Request since you converted it to >>> Enhancement: >>>> >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html >>>> >>>> Someone from Oracle have to sponsor it and do related closed code >>> changes and testing. >>> >>> webrev.03 looks good to me. I did the necessary closed changes (review is >>> pending) and also adapted some of the public code. >>> >>> Incremental webrev: >>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >>> >>> I removed the PPC code because since 8u33, SE Embedded releases no >>> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM specific >>> code into the closed sources. I adapted the copyright dates and refactored >>> some related code. >>> >>> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks for >>> is_valid() which is false for fnoreg. We should check for >>> 'as_FloatRegister(reg2) != fnoreg'. >>> >>> Tests are running. >>> >>> Best regards, >>> Tobias >>> >>> [1] http://www.oracle.com/technetwork/java/embedded/embedded- >>> se/downloads/index.html >>> [2] http://www.oracle.com/technetwork/java/javase/certconfig- >>> 2095354.html >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> could someone please have a look at this issue? I recap the description >>>>> below, and I also updated the webrev which would no more apply to >>>>> hs-comp: >>>>> >>>>> c1_LIR.hpp defines a row of functions guarded by platform >>>>> defines. This is bad style and hinders new platform ports. >>>>> (I'm working on S390 aka Z :)) >>>>> >>>>> This change removes the majority of these defines. It introduces >>>>> common headers, and moves implementations to c1_LIR_.cpp files. >>>>> >>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>>> This is not used in any openJdk platform. I can not test this >>>>> on the closed platforms ARM32 and PPC32. >>>>> >>>>> It removes the guard around the LIR_Address constructor. There >>>>> is no point in guarding this code, verify() assures by >>>>> assertions that it can not be misused. I also introduce a new >>>>> constructor that leaves out the scale argument and introduce >>>>> some usages on X86. >>>>> >>>>> This change also moves verify() to the new platform files. In the >>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>>> >>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>>> it should be moved to according new files c1_LIR_.cpp in >>>>> the closed ports. But this way the change should basically >>>>> work for the closed ports. >>>>> >>>>> I added fnoreg on x86 to note down the code similarly on all >>>>> platforms. >>>>> >>>>> I cleaned up a flag with a limited range on PPC_32. >>>>> >>>>> generate_stack_overflow_check() in templateInterpreterGenerator.hpp >>>>> is defined with different parameters for the platforms. I added default >>>>> parameters noreg so that the signature is the same for all platforms. >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.02/ >>>>> >>>>> I built and tested this on linuxx86_64, solaris_sparc and >>>>> the ppc platforms. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From goetz.lindenmaier at sap.com Thu Jul 14 06:25:06 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 06:25:06 +0000 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <578728F6.2060306@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> <5784EB7A.3000608@oracle.com> <578728F6.2060306@oracle.com> Message-ID: <7921c3aa4efd40abb3755cff3d97b699@DEWDFE13DE09.global.corp.sap> Hi Tobias, don't we have to wait until the enhancement is accepted? The bug still has tag jdk9-fc-request. https://bugs.openjdk.java.net/browse/JDK-8160245 Best regards, Goetz. > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Thursday, July 14, 2016 7:54 AM > To: Lindenmaier, Goetz ; Vladimir Kozlov > ; hotspot-compiler-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net runtime dev at openjdk.java.net> > Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > c1_LIR.hpp. > > Hi, > > all tests passed. If everyone's fine with the latest webrev, I'll push this > tomorrow: > http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ > > Goetz, could you please send me a changeset? > > Thanks, > Tobias > > On 12.07.2016 15:07, Tobias Hartmann wrote: > > Hi Goetz, > > > > On 12.07.2016 15:03, Lindenmaier, Goetz wrote: > >> Hi Tobias, > >> > >> thanks for looking at this change! Your additional edits look good. > >> Thanks for spotting the problems. Unfortunately, we don't have > >> an aarch machine. > > > > Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on > SPARC. > > > >> I also had problems with these asserts, as_FloatRegister(reg2) > >> was not possible on ppc because it did not like the '-1'. But that's > >> fixed already. > > > > Yes, I noticed that. > > > >> Good to know there is no PPC32 any more. I always had to take > >> care I don't break anything in this 'invisible team mate' on Power :) > >> > >> Do you want me to make a new webrev with your edits? I'm > >> fine with the webrev you mailed around, though. I tested it to > >> work on ppc, and I'll run it through our tests tonight. > > > > You don't have to create a new webrev. If all testing passed and the other > reviewers agree with the latest webrev, you can send me a changeset and I'll > push it. > > > > Best regards, > > Tobias > > > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > >>> Sent: Dienstag, 12. Juli 2016 14:34 > >>> To: Vladimir Kozlov ; Lindenmaier, Goetz > >>> ; hotspot-compiler- > dev at openjdk.java.net > >>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>> dev at openjdk.java.net> > >>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > >>> c1_LIR.hpp. > >>> > >>> Hi Goetz, > >>> > >>> On 06.07.2016 00:47, Vladimir Kozlov wrote: > >>>> CC to runtime too since it has changes in Interpreter and affects our > closed > >>> code. > >>>> > >>>> Hi Goetz, > >>>> > >>>> Please, set "Fix Version". > >>>> > >>>> And if it is JDK 9 you need FC Extension Request since you converted it > to > >>> Enhancement: > >>>> > >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > June/004443.html > >>>> > >>>> Someone from Oracle have to sponsor it and do related closed code > >>> changes and testing. > >>> > >>> webrev.03 looks good to me. I did the necessary closed changes (review > is > >>> pending) and also adapted some of the public code. > >>> > >>> Incremental webrev: > >>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ > >>> > >>> Full webrev: > >>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ > >>> > >>> I removed the PPC code because since 8u33, SE Embedded releases no > >>> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM > specific > >>> code into the closed sources. I adapted the copyright dates and > refactored > >>> some related code. > >>> > >>> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks > for > >>> is_valid() which is false for fnoreg. We should check for > >>> 'as_FloatRegister(reg2) != fnoreg'. > >>> > >>> Tests are running. > >>> > >>> Best regards, > >>> Tobias > >>> > >>> [1] http://www.oracle.com/technetwork/java/embedded/embedded- > >>> se/downloads/index.html > >>> [2] http://www.oracle.com/technetwork/java/javase/certconfig- > >>> 2095354.html > >>> > >>>> Thanks, > >>>> Vladimir > >>>> > >>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> could someone please have a look at this issue? I recap the > description > >>>>> below, and I also updated the webrev which would no more apply to > >>>>> hs-comp: > >>>>> > >>>>> c1_LIR.hpp defines a row of functions guarded by platform > >>>>> defines. This is bad style and hinders new platform ports. > >>>>> (I'm working on S390 aka Z :)) > >>>>> > >>>>> This change removes the majority of these defines. It introduces > >>>>> common headers, and moves implementations to c1_LIR_.cpp > files. > >>>>> > >>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. > >>>>> This is not used in any openJdk platform. I can not test this > >>>>> on the closed platforms ARM32 and PPC32. > >>>>> > >>>>> It removes the guard around the LIR_Address constructor. There > >>>>> is no point in guarding this code, verify() assures by > >>>>> assertions that it can not be misused. I also introduce a new > >>>>> constructor that leaves out the scale argument and introduce > >>>>> some usages on X86. > >>>>> > >>>>> This change also moves verify() to the new platform files. In the > >>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage > >>>>> of pd_verify(). Neither of these are used in openJdk. If this define > >>>>> is used in the closed ports pd_verify() must be renamed to verify(). > >>>>> > >>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is > >>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, > >>>>> it should be moved to according new files c1_LIR_.cpp in > >>>>> the closed ports. But this way the change should basically > >>>>> work for the closed ports. > >>>>> > >>>>> I added fnoreg on x86 to note down the code similarly on all > >>>>> platforms. > >>>>> > >>>>> I cleaned up a flag with a limited range on PPC_32. > >>>>> > >>>>> generate_stack_overflow_check() in > templateInterpreterGenerator.hpp > >>>>> is defined with different parameters for the platforms. I added default > >>>>> parameters noreg so that the signature is the same for all platforms. > >>>>> > >>>>> Please review this change. I please need a sponsor. > >>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- > simplifyC1/webrev.02/ > >>>>> > >>>>> I built and tested this on linuxx86_64, solaris_sparc and > >>>>> the ppc platforms. > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From tobias.hartmann at oracle.com Thu Jul 14 06:28:15 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jul 2016 08:28:15 +0200 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <7921c3aa4efd40abb3755cff3d97b699@DEWDFE13DE09.global.corp.sap> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> <5784EB7A.3000608@oracle.com> <578728F6.2060306@oracle.com> <7921c3aa4efd40abb3755cff3d97b699@DEWDFE13DE09.global.corp.sap> Message-ID: <578730FF.1030208@oracle.com> Hi Goetz, Vladimir K. already approved the request but I think he forgot to add the 'jdk9-fc-yes' label. Let's wait for him to do that. Best regards, Tobias On 14.07.2016 08:25, Lindenmaier, Goetz wrote: > Hi Tobias, > > don't we have to wait until the enhancement is accepted? > The bug still has tag jdk9-fc-request. > https://bugs.openjdk.java.net/browse/JDK-8160245 > > Best regards, > Goetz. > > > > >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Thursday, July 14, 2016 7:54 AM >> To: Lindenmaier, Goetz ; Vladimir Kozlov >> ; hotspot-compiler-dev at openjdk.java.net >> Cc: hotspot-runtime-dev at openjdk.java.net runtime > dev at openjdk.java.net> >> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >> c1_LIR.hpp. >> >> Hi, >> >> all tests passed. If everyone's fine with the latest webrev, I'll push this >> tomorrow: >> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >> >> Goetz, could you please send me a changeset? >> >> Thanks, >> Tobias >> >> On 12.07.2016 15:07, Tobias Hartmann wrote: >>> Hi Goetz, >>> >>> On 12.07.2016 15:03, Lindenmaier, Goetz wrote: >>>> Hi Tobias, >>>> >>>> thanks for looking at this change! Your additional edits look good. >>>> Thanks for spotting the problems. Unfortunately, we don't have >>>> an aarch machine. >>> >>> Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on >> SPARC. >>> >>>> I also had problems with these asserts, as_FloatRegister(reg2) >>>> was not possible on ppc because it did not like the '-1'. But that's >>>> fixed already. >>> >>> Yes, I noticed that. >>> >>>> Good to know there is no PPC32 any more. I always had to take >>>> care I don't break anything in this 'invisible team mate' on Power :) >>>> >>>> Do you want me to make a new webrev with your edits? I'm >>>> fine with the webrev you mailed around, though. I tested it to >>>> work on ppc, and I'll run it through our tests tonight. >>> >>> You don't have to create a new webrev. If all testing passed and the other >> reviewers agree with the latest webrev, you can send me a changeset and I'll >> push it. >>> >>> Best regards, >>> Tobias >>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>>>> Sent: Dienstag, 12. Juli 2016 14:34 >>>>> To: Vladimir Kozlov ; Lindenmaier, Goetz >>>>> ; hotspot-compiler- >> dev at openjdk.java.net >>>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>>> dev at openjdk.java.net> >>>>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>>>> c1_LIR.hpp. >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 06.07.2016 00:47, Vladimir Kozlov wrote: >>>>>> CC to runtime too since it has changes in Interpreter and affects our >> closed >>>>> code. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Please, set "Fix Version". >>>>>> >>>>>> And if it is JDK 9 you need FC Extension Request since you converted it >> to >>>>> Enhancement: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >> June/004443.html >>>>>> >>>>>> Someone from Oracle have to sponsor it and do related closed code >>>>> changes and testing. >>>>> >>>>> webrev.03 looks good to me. I did the necessary closed changes (review >> is >>>>> pending) and also adapted some of the public code. >>>>> >>>>> Incremental webrev: >>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ >>>>> >>>>> Full webrev: >>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >>>>> >>>>> I removed the PPC code because since 8u33, SE Embedded releases no >>>>> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM >> specific >>>>> code into the closed sources. I adapted the copyright dates and >> refactored >>>>> some related code. >>>>> >>>>> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks >> for >>>>> is_valid() which is false for fnoreg. We should check for >>>>> 'as_FloatRegister(reg2) != fnoreg'. >>>>> >>>>> Tests are running. >>>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>> [1] http://www.oracle.com/technetwork/java/embedded/embedded- >>>>> se/downloads/index.html >>>>> [2] http://www.oracle.com/technetwork/java/javase/certconfig- >>>>> 2095354.html >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could someone please have a look at this issue? I recap the >> description >>>>>>> below, and I also updated the webrev which would no more apply to >>>>>>> hs-comp: >>>>>>> >>>>>>> c1_LIR.hpp defines a row of functions guarded by platform >>>>>>> defines. This is bad style and hinders new platform ports. >>>>>>> (I'm working on S390 aka Z :)) >>>>>>> >>>>>>> This change removes the majority of these defines. It introduces >>>>>>> common headers, and moves implementations to c1_LIR_.cpp >> files. >>>>>>> >>>>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>>>>> This is not used in any openJdk platform. I can not test this >>>>>>> on the closed platforms ARM32 and PPC32. >>>>>>> >>>>>>> It removes the guard around the LIR_Address constructor. There >>>>>>> is no point in guarding this code, verify() assures by >>>>>>> assertions that it can not be misused. I also introduce a new >>>>>>> constructor that leaves out the scale argument and introduce >>>>>>> some usages on X86. >>>>>>> >>>>>>> This change also moves verify() to the new platform files. In the >>>>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>>>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>>>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>>>>> >>>>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>>>>> it should be moved to according new files c1_LIR_.cpp in >>>>>>> the closed ports. But this way the change should basically >>>>>>> work for the closed ports. >>>>>>> >>>>>>> I added fnoreg on x86 to note down the code similarly on all >>>>>>> platforms. >>>>>>> >>>>>>> I cleaned up a flag with a limited range on PPC_32. >>>>>>> >>>>>>> generate_stack_overflow_check() in >> templateInterpreterGenerator.hpp >>>>>>> is defined with different parameters for the platforms. I added default >>>>>>> parameters noreg so that the signature is the same for all platforms. >>>>>>> >>>>>>> Please review this change. I please need a sponsor. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- >> simplifyC1/webrev.02/ >>>>>>> >>>>>>> I built and tested this on linuxx86_64, solaris_sparc and >>>>>>> the ppc platforms. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> From Alan.Burlison at oracle.com Thu Jul 14 07:52:53 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 14 Jul 2016 08:52:53 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> Message-ID: <578744D5.7060300@oracle.com> On 14/07/2016 02:20, David Holmes wrote: > One query: if pwd.h is not the last file included don't we need to undef > _POSIX_PTHREAD_SEMANTICS again to ensure no other included definitions > are affected? If we don't need to do that then I wonder whether > _POSIX_PTHREAD_SEMANTICS should not simply be set via the build system > for all compilations? _POSIX_PTHREAD_SEMANTICS only affects a few APIs which changed between POSIX.1c Draft 6 and POSIX 1003.1c - Solaris implemented the draft version due to release scheduling issues, which was a mistake. Some of the differences don't matter for LP64 apps such as Java, the other APIs are less-frequently used. The main problems you tend to see are the user/group iteration APIs (as in this case) and directory enumeration. You could undef _POSIX_PTHREAD_SEMANTICS if you wanted but there's no real benefit and it would add yet more clutter. As for setting it globally, no that wouldn't be a good idea. It's a workaround for a problem that will be gone in later Solaris releases, where you'll get the POSIX 1003.1c definitions by default and will have to explicitly ask for the old draft ones. At that point defining _POSIX_PTHREAD_SEMANTICS will have no effect. It is a transitional workaround for a misfeature and as such I believe needs to be restricted as much as possible by just adding it to the affected files, and then removing it altogether as soon as possible. -- Alan Burlison -- From goetz.lindenmaier at sap.com Thu Jul 14 08:49:52 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 08:49:52 +0000 Subject: RFR(L): 8161259: Simplify including platform files. Message-ID: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> Hi, this change simplifies the include cascades used to include platform headers. The direcitves -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_MODEL_x86_64 -DTARGET_ARCH_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_OS_ARCH_linux_x86 are replaced by -DINCLUDE_SUFFIX_OS=linux -DINCLUDE_SUFFIX_CPU=x86. In utilities/macros.hpp there are macros that use these two defines and constuct platform header names from them. So this cascade: #ifdef TARGET_ARCH_x86 # include "assembler_x86.hpp" #endif #ifdef TARGET_ARCH_sparc # include "assembler_sparc.hpp" #endif #ifdef TARGET_ARCH_zero # include "assembler_zero.hpp" #endif #ifdef TARGET_ARCH_arm # include "assembler_arm.hpp" #endif #ifdef TARGET_ARCH_ppc # include "assembler_ppc.hpp" #endif #ifdef TARGET_ARCH_aarch64 # include "assembler_aarch64.hpp" #endif now is replaced by this one include #include cpu_header(assembler) One problem with the macros is that there exist macros 'linux' and 'sparc' (lowercase!). Therefore using INCLUDE_SUFFIX_OS etc fails in this two cases. Luckily, with the new setup, special casing for this can all be done in macros.hpp. There are some places where above old TARGET_... macros were used for other purposes than guarding the includes, I replaced them to use the platform dependent macros (LINUX, X86 ...) already defined. I also removed all headers carying _64 or _32 in their name. There were three of them on ppc. As I learned there is no closed PPC32 port any more, I just renamed the without the _64 suffix. I found one on x86 (stubRoutines_...hpp). I merged it and used LP64 guards for the differences. I think this is acceptable as the files are rather small and it's the only case. The adlc generated files all had suffix _64/_32 which I removed. These are not significant, either, because 32-bit and 64-bit VM should be built in different directories. Also, in the pre-discussion to this change we found that the mutex platform files are empty. Thus I removed them. Please review this webrev. I please need a sponsor: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.01/ To view the core of this change, look at CompileJvm.gmk and utilities/macros.hpp. I include hs-comp due to the changes in CompileAdlc.gmk. I compiled the webrev on the following platforms: linux_x86_64, linux_ppc64, linux_ppc64le, linux_zero(x86_64) aix_ppc64 bsd_x86_64 windows_x86_64 solaris_sparc Best regards, Goetz. From goetz.lindenmaier at sap.com Thu Jul 14 09:19:46 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 09:19:46 +0000 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <578730FF.1030208@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> <5784EB7A.3000608@oracle.com> <578728F6.2060306@oracle.com> <7921c3aa4efd40abb3755cff3d97b699@DEWDFE13DE09.global.corp.sap> <578730FF.1030208@oracle.com> Message-ID: <2ecd16ff04dd4af5aa5d0e9c6afc491e@DEWDFE13DE09.global.corp.sap> Hi Tobias, here is a final webrev including a jchecked changeset: http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.04/ Thanks a lot for your help! Best regards, Goetz. > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Donnerstag, 14. Juli 2016 08:28 > To: Lindenmaier, Goetz ; Vladimir Kozlov > ; hotspot-compiler-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net runtime dev at openjdk.java.net> > Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > c1_LIR.hpp. > > Hi Goetz, > > Vladimir K. already approved the request but I think he forgot to add the > 'jdk9-fc-yes' label. Let's wait for him to do that. > > Best regards, > Tobias > > On 14.07.2016 08:25, Lindenmaier, Goetz wrote: > > Hi Tobias, > > > > don't we have to wait until the enhancement is accepted? > > The bug still has tag jdk9-fc-request. > > https://bugs.openjdk.java.net/browse/JDK-8160245 > > > > Best regards, > > Goetz. > > > > > > > > > >> -----Original Message----- > >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > >> Sent: Thursday, July 14, 2016 7:54 AM > >> To: Lindenmaier, Goetz ; Vladimir Kozlov > >> ; hotspot-compiler-dev at openjdk.java.net > >> Cc: hotspot-runtime-dev at openjdk.java.net runtime >> dev at openjdk.java.net> > >> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > >> c1_LIR.hpp. > >> > >> Hi, > >> > >> all tests passed. If everyone's fine with the latest webrev, I'll push this > >> tomorrow: > >> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ > >> > >> Goetz, could you please send me a changeset? > >> > >> Thanks, > >> Tobias > >> > >> On 12.07.2016 15:07, Tobias Hartmann wrote: > >>> Hi Goetz, > >>> > >>> On 12.07.2016 15:03, Lindenmaier, Goetz wrote: > >>>> Hi Tobias, > >>>> > >>>> thanks for looking at this change! Your additional edits look good. > >>>> Thanks for spotting the problems. Unfortunately, we don't have > >>>> an aarch machine. > >>> > >>> Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on > >> SPARC. > >>> > >>>> I also had problems with these asserts, as_FloatRegister(reg2) > >>>> was not possible on ppc because it did not like the '-1'. But that's > >>>> fixed already. > >>> > >>> Yes, I noticed that. > >>> > >>>> Good to know there is no PPC32 any more. I always had to take > >>>> care I don't break anything in this 'invisible team mate' on Power :) > >>>> > >>>> Do you want me to make a new webrev with your edits? I'm > >>>> fine with the webrev you mailed around, though. I tested it to > >>>> work on ppc, and I'll run it through our tests tonight. > >>> > >>> You don't have to create a new webrev. If all testing passed and the > other > >> reviewers agree with the latest webrev, you can send me a changeset > and I'll > >> push it. > >>> > >>> Best regards, > >>> Tobias > >>> > >>>> Best regards, > >>>> Goetz. > >>>> > >>>>> -----Original Message----- > >>>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > >>>>> Sent: Dienstag, 12. Juli 2016 14:34 > >>>>> To: Vladimir Kozlov ; Lindenmaier, > Goetz > >>>>> ; hotspot-compiler- > >> dev at openjdk.java.net > >>>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime runtime- > >>>>> dev at openjdk.java.net> > >>>>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in > >>>>> c1_LIR.hpp. > >>>>> > >>>>> Hi Goetz, > >>>>> > >>>>> On 06.07.2016 00:47, Vladimir Kozlov wrote: > >>>>>> CC to runtime too since it has changes in Interpreter and affects our > >> closed > >>>>> code. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> Please, set "Fix Version". > >>>>>> > >>>>>> And if it is JDK 9 you need FC Extension Request since you converted > it > >> to > >>>>> Enhancement: > >>>>>> > >>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > >> June/004443.html > >>>>>> > >>>>>> Someone from Oracle have to sponsor it and do related closed code > >>>>> changes and testing. > >>>>> > >>>>> webrev.03 looks good to me. I did the necessary closed changes > (review > >> is > >>>>> pending) and also adapted some of the public code. > >>>>> > >>>>> Incremental webrev: > >>>>> > http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ > >>>>> > >>>>> Full webrev: > >>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ > >>>>> > >>>>> I removed the PPC code because since 8u33, SE Embedded releases > no > >>>>> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM > >> specific > >>>>> code into the closed sources. I adapted the copyright dates and > >> refactored > >>>>> some related code. > >>>>> > >>>>> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() > checks > >> for > >>>>> is_valid() which is false for fnoreg. We should check for > >>>>> 'as_FloatRegister(reg2) != fnoreg'. > >>>>> > >>>>> Tests are running. > >>>>> > >>>>> Best regards, > >>>>> Tobias > >>>>> > >>>>> [1] > http://www.oracle.com/technetwork/java/embedded/embedded- > >>>>> se/downloads/index.html > >>>>> [2] http://www.oracle.com/technetwork/java/javase/certconfig- > >>>>> 2095354.html > >>>>> > >>>>>> Thanks, > >>>>>> Vladimir > >>>>>> > >>>>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> could someone please have a look at this issue? I recap the > >> description > >>>>>>> below, and I also updated the webrev which would no more apply > to > >>>>>>> hs-comp: > >>>>>>> > >>>>>>> c1_LIR.hpp defines a row of functions guarded by platform > >>>>>>> defines. This is bad style and hinders new platform ports. > >>>>>>> (I'm working on S390 aka Z :)) > >>>>>>> > >>>>>>> This change removes the majority of these defines. It introduces > >>>>>>> common headers, and moves implementations to > c1_LIR_.cpp > >> files. > >>>>>>> > >>>>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. > >>>>>>> This is not used in any openJdk platform. I can not test this > >>>>>>> on the closed platforms ARM32 and PPC32. > >>>>>>> > >>>>>>> It removes the guard around the LIR_Address constructor. There > >>>>>>> is no point in guarding this code, verify() assures by > >>>>>>> assertions that it can not be misused. I also introduce a new > >>>>>>> constructor that leaves out the scale argument and introduce > >>>>>>> some usages on X86. > >>>>>>> > >>>>>>> This change also moves verify() to the new platform files. In the > >>>>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage > >>>>>>> of pd_verify(). Neither of these are used in openJdk. If this define > >>>>>>> is used in the closed ports pd_verify() must be renamed to verify(). > >>>>>>> > >>>>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is > >>>>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, > >>>>>>> it should be moved to according new files c1_LIR_.cpp in > >>>>>>> the closed ports. But this way the change should basically > >>>>>>> work for the closed ports. > >>>>>>> > >>>>>>> I added fnoreg on x86 to note down the code similarly on all > >>>>>>> platforms. > >>>>>>> > >>>>>>> I cleaned up a flag with a limited range on PPC_32. > >>>>>>> > >>>>>>> generate_stack_overflow_check() in > >> templateInterpreterGenerator.hpp > >>>>>>> is defined with different parameters for the platforms. I added > default > >>>>>>> parameters noreg so that the signature is the same for all > platforms. > >>>>>>> > >>>>>>> Please review this change. I please need a sponsor. > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- > >> simplifyC1/webrev.02/ > >>>>>>> > >>>>>>> I built and tested this on linuxx86_64, solaris_sparc and > >>>>>>> the ppc platforms. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> From goetz.lindenmaier at sap.com Thu Jul 14 10:40:02 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 10:40:02 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <57876129.8000303@redhat.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> Message-ID: <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> Hmm, how do you define CONCAT? I guess that's the tricky part. Best regards, Goetz. > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Donnerstag, 14. Juli 2016 11:54 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Hi, > > On 14/07/16 10:17, Lindenmaier, Goetz wrote: > > >> Are we really happy with > >> 40 #define SUB(x) x > >> > >> SUB is a very generic name, and this is some very weird macro hacking. > >> At least we need an explanation in a comment. > > > > That's a good point, I'll rename it to HSSUB (hotspot submacro). > > It should not be too long because it's used so often on one line. > > How about > > 480 # define xos_cpu_header(x, y) > XSTR(SUB(x)SUB(_)SUB(INCLUDE_SUFFIX_OS)SUB(_sparc)SUB(y)) > > --> > > 480 # define xos_cpu_header(x, y) > XSTR(CONCAT(x,_)CONCAT(INCLUDE_SUFFIX_OS,CONCAT(_sparc,y))) > > or maybe even > > 480 # define xos_cpu_header(x, y) > CONCAT5(x,_,INCLUDE_SUFFIX_OS,_sparc,y) > > I would have understood immediately what that was doing. > > Andrew. From aph at redhat.com Thu Jul 14 11:41:38 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jul 2016 12:41:38 +0100 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> Message-ID: <57877A72.5050405@redhat.com> On 14/07/16 11:40, Lindenmaier, Goetz wrote: > Hmm, how do you define CONCAT? #define CONCAT5(a, b, c, d, e) a ## b ## c ## d ## e CONCAT5(Twas,Brillig,And,The,Slithy) Andrew. From goetz.lindenmaier at sap.com Thu Jul 14 12:42:42 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 12:42:42 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <57877A72.5050405@redhat.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> Message-ID: <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> Hi Andrew, unfortunately it's not that simple ... It does not grok the macro INCLUDE_SUFFIX_CPU, nor the dot in .hpp: #define CONCAT4(a, b, c, d) a ## b ## c ## d #define xcpu_header(x, y) XSTR(CONCAT4(x, _, INCLUDE_SUFFIX_CPU, y)) #define cpu_header(basename) xcpu_header(basename,.hpp) cpu_header(globalDefinitions) error: pasting "globalDefinitions_INCLUDE_SUFFIX_CPU" and "." does not give a valid preprocessing token Best regards, Goetz > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Donnerstag, 14. Juli 2016 13:42 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 14/07/16 11:40, Lindenmaier, Goetz wrote: > > Hmm, how do you define CONCAT? > > #define CONCAT5(a, b, c, d, e) a ## b ## c ## d ## e > CONCAT5(Twas,Brillig,And,The,Slithy) > > Andrew. From ioi.lam at oracle.com Thu Jul 14 12:47:11 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 14 Jul 2016 05:47:11 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> Message-ID: <578789CF.3050902@oracle.com> Hi Jiangli, I think these are not necessary in systemDictionary.cpp, as the same condition is checked in the "inner" load_share_class() function. 1249 // Don't load shared class when JvmtiExport::should_post_class_file_load_hook() 1250 // is enabled since posting CFLH is not supported when loading shared class. 1251 if (!JvmtiExport::should_post_class_file_load_hook()) { The rest looks OK to me. Thanks - Ioi On 7/13/16 5:06 PM, Jiangli Zhou wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ > > Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). > Agent specified via command line: > With -Xshare:on, report error and exit. > Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. > With -Xshare:auto, disallow loading shared class > If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). > If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). > Agent is attached: > With -Xshare:on and -Xshare:auto > Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. > Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the > 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. > > Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. > > Thanks, > Jiangli > > > >> On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: >> >> Hi Ioi, >> >>> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >>> >>> Hi Jiangli, >>> >>> I agree what what Karen has said. >>> >>> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >>> >>> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. >> Agreed. >> >>> Also, maybe this check can also be removed? >>> >>> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >>> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >>> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >>> >>> Since the same check is already done in the "inner" load_shared_class() method. >> I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. >> >> Thanks, >> Jiangli >> >>> Thanks >>> - Ioi >>> >>> >>> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>>> Hi Karen, >>>> >>>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>>> >>>>> Jiangli, >>>>> >>>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>>> >>>>> I agree with not quitting the vm on agent attach. >>>>> I actually think we also want the agent attach to succeed - see below. >>>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>>> >>>>>> (Adding serviceability-dev at openjdk.java.net) >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> I think the two blocks of >>>>>> >>>>>> if (RequireSharedSpaces) { >>>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>>> vm_exit(1); >>>>>> } >>>>>> >>>>>> should be removed. >>>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>>> but no forcing of using the shared spaces if there is an agent. >>>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>>> Totally agree - we should not quit the VM. >>>>> >>>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>>> >>>>>> jvmtiError >>>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>>> >>>>>> ... >>>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>>> + } >>>>>> record_class_file_load_hook_enabled(); >>>>>> } >>>>>> ? >>>>>> } >>>>>> >>>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>>> Thanks >>>>>> - Ioi >>>>> Jiangli: >>>>> >>>>> Minor code review comments: >>>>> >>>>> metaspace.cpp line 3181: CFHL-> CFLH >>>>> >>>>> metaspace.cpp: >>>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>>> >>>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>>> bug: JDK-8141341 >>>>>>> >>>>>>> With -Xshare:on >>>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>>> >>>>>>> With -Xshare:auto >>>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>>> >>>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>> From gerard.ziemski at oracle.com Thu Jul 14 14:17:42 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 14 Jul 2016 09:17:42 -0500 Subject: RFR (M): JDK-8138760: [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: References: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> Message-ID: <87E86251-1C9E-478E-9AA0-F6F0A2556BA2@oracle.com> Thank you! > On Jul 13, 2016, at 7:37 PM, David Holmes wrote: > > Looks good! Thanks Gerard. > > David > > On 14/07/2016 5:31 AM, Gerard Ziemski wrote: >> hi all, >> >> Here is a webrev 2, which incorporates the following feedback: >> >> #1. Changed ?debug_only" to ?DEBUG_ONLY" (Christian, David), including all instances in the files where I used the macros >> >> #2. Fixed the ?for? loops (David) >> >> #3. Using ?unsigned? for hit counter instead of "long" (Ioi) >> >> #4. Changed the help message (Ioi) >> >> #5. Changed how I print ?%? (Ioi) >> >> webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev2 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> >>> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >>> >>> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >>> >>> ----------------------------- >>> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >>> Java system dictionary (table_size=1009, classes=484) >>> ^ indicates that initiating loader is different from defining loader >>> 1st number shows bucket index >>> 2nd number shows chain index within a bucket >>> 3rd number shows hit percentage of the bucket >>> 4th number shows hash index >>> 0: >>> 1: >>> 2: >>> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >>> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >>> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >>> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >>> 5: >>> . >>> . >>> . >>> 1003: >>> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >>> 1005: >>> 1006: >>> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >>> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >>> >>> Top 16 buckets: >>> 546: hits 2.76% >>> 183: hits 0.87% >>> 969: hits 2.37%s >>> 281: hits 0.95% >>> 957: hits 1.73% >>> 571: hits 16.67% >>> 221: hits 0.98% >>> 505: hits 0.84% >>> 727: hits 1.28% >>> 414: hits 1.73% >>> 569: hits 4.89% >>> 245: hits 0.89% >>> 253: hits 1.34% >>> 135: hits 0.95% >>> 457: hits 0.87% >>> 348: hits 1.23% >>> >>> Protection domain cache table (table_size=2017, classes=1) >>> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >>> ----------------------------- >>> >>> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >>> >>> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >>> >>> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >>> closed webrev: http://javaweb.us.oracle.com/~gziemski/webrevs/8138760_rev1 >>> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >>> >>> Passes JPRT hotspot. >> >> cheers >> From gerard.ziemski at oracle.com Thu Jul 14 14:17:50 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 14 Jul 2016 09:17:50 -0500 Subject: RFR (M): JDK-8138760: [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 In-Reply-To: <5786FFAA.1060502@oracle.com> References: <1065EA55-E28D-444D-B39B-20AB4D9EC101@oracle.com> <5786FFAA.1060502@oracle.com> Message-ID: <59E810B1-7AA2-4AE0-993A-F3746C05F709@oracle.com> Thank you! > On Jul 13, 2016, at 9:57 PM, Ioi Lam wrote: > > Hi Gerard, > > Looks good. > > Thanks > - Ioi > > On 7/13/16 12:31 PM, Gerard Ziemski wrote: >> hi all, >> >> Here is a webrev 2, which incorporates the following feedback: >> >> #1. Changed ?debug_only" to ?DEBUG_ONLY" (Christian, David), including all instances in the files where I used the macros >> >> #2. Fixed the ?for? loops (David) >> >> #3. Using ?unsigned? for hit counter instead of "long" (Ioi) >> >> #4. Changed the help message (Ioi) >> >> #5. Changed how I print ?%? (Ioi) >> >> webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev2 >> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >> >> >>> Please review this rather simple fix, which will print more info about SystemDictionary, so that we can hopefully draw some conclusion the next time we hit the ?VM warning: Performance bug: SystemDictionary?? warning. >>> >>> Currently all we print is just the warning's 1st line below, but with this fix we show the following: >>> >>> ----------------------------- >>> Java HotSpot(TM) 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=6752 lookup_length=1010 average=0.149585 load=0.479683 >>> Java system dictionary (table_size=1009, classes=484) >>> ^ indicates that initiating loader is different from defining loader >>> 1st number shows bucket index >>> 2nd number shows chain index within a bucket >>> 3rd number shows hit percentage of the bucket >>> 4th number shows hash index >>> 0: >>> 1: >>> 2: >>> 3: 0: 0.20%: 1763306205: jdk.internal.module.ModuleHashes, loader NULL class_loader >>> 3: 1: 0.20%: 1886526294: sun.nio.fs.UnixFileStoreAttributes, loader NULL class_loader >>> 3: 2: 0.20%: 220125461: java.lang.reflect.ReflectAccess, loader NULL class_loader >>> 4: 0: 0.08%: 915402137: jdk.internal.loader.BuiltinClassLoader$LoadedModule, loader NULL class_loader >>> 5: >>> . >>> . >>> . >>> 1003: >>> 1004: 0: 0.08%: 688417488: jdk.internal.reflect.ConstructorAccessor, loader NULL class_loader >>> 1005: >>> 1006: >>> 1007: 0: 0.08%: 400327811: java.lang.InterruptedException, loader NULL class_loader >>> 1008: 0: 0.11%: 1113735208: java.util.concurrent.atomic.AtomicBoolean, loader NULL class_loader >>> >>> Top 16 buckets: >>> 546: hits 2.76% >>> 183: hits 0.87% >>> 969: hits 2.37%s >>> 281: hits 0.95% >>> 957: hits 1.73% >>> 571: hits 16.67% >>> 221: hits 0.98% >>> 505: hits 0.84% >>> 727: hits 1.28% >>> 414: hits 1.73% >>> 569: hits 4.89% >>> 245: hits 0.89% >>> 253: hits 1.34% >>> 135: hits 0.95% >>> 457: hits 0.87% >>> 348: hits 1.23% >>> >>> Protection domain cache table (table_size=2017, classes=1) >>> entry 0x00007fe525019c20 value 0x00000006cfe147a8 strongly_reachable 0 next 0x0000000000000000 >>> ----------------------------- >>> >>> We now show the bucket index, the chain index (item index within the bucket), the hit ratio (successful lookup / all successful lookups) and hash code for verification. >>> >>> In the end, I believe that the way to actually fix this issue will be to increase the SystemDictionary size, but the warning will be now accompanied by more pertinent details, which should make it more useful on its own. >>> >>> open webrev: http://cr.openjdk.java.net/~gziemski/8138760_rev1 >>> closed webrev: http://javaweb.us.oracle.com/~gziemski/webrevs/8138760_rev1 >>> bug id: https://bugs.openjdk.java.net/browse/JDK-8138760 >>> >>> Passes JPRT hotspot. >> cheers >> > From daniel.daugherty at oracle.com Thu Jul 14 15:32:20 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 09:32:20 -0600 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <578730FF.1030208@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> <5784EB7A.3000608@oracle.com> <578728F6.2060306@oracle.com> <7921c3aa4efd40abb3755cff3d97b699@DEWDFE13DE09.global.corp.sap> <578730FF.1030208@oracle.com> Message-ID: <7a6717e6-919d-77c7-f678-cea873f1ca88@oracle.com> Vladimir H. has to approve the request as the Hotspot Group lead. The next step is the JDK9 Release Team which discusses FC requests on Thursdays so it should be today... After the Release Team approves, Vladimir will set the 'jdk9-fc-yes' label. Dan On 7/14/16 12:28 AM, Tobias Hartmann wrote: > Hi Goetz, > > Vladimir K. already approved the request but I think he forgot to add the 'jdk9-fc-yes' label. Let's wait for him to do that. > > Best regards, > Tobias > > On 14.07.2016 08:25, Lindenmaier, Goetz wrote: >> Hi Tobias, >> >> don't we have to wait until the enhancement is accepted? >> The bug still has tag jdk9-fc-request. >> https://bugs.openjdk.java.net/browse/JDK-8160245 >> >> Best regards, >> Goetz. >> >> >> >> >>> -----Original Message----- >>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>> Sent: Thursday, July 14, 2016 7:54 AM >>> To: Lindenmaier, Goetz ; Vladimir Kozlov >>> ; hotspot-compiler-dev at openjdk.java.net >>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >> dev at openjdk.java.net> >>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>> c1_LIR.hpp. >>> >>> Hi, >>> >>> all tests passed. If everyone's fine with the latest webrev, I'll push this >>> tomorrow: >>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >>> >>> Goetz, could you please send me a changeset? >>> >>> Thanks, >>> Tobias >>> >>> On 12.07.2016 15:07, Tobias Hartmann wrote: >>>> Hi Goetz, >>>> >>>> On 12.07.2016 15:03, Lindenmaier, Goetz wrote: >>>>> Hi Tobias, >>>>> >>>>> thanks for looking at this change! Your additional edits look good. >>>>> Thanks for spotting the problems. Unfortunately, we don't have >>>>> an aarch machine. >>>> Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on >>> SPARC. >>>>> I also had problems with these asserts, as_FloatRegister(reg2) >>>>> was not possible on ppc because it did not like the '-1'. But that's >>>>> fixed already. >>>> Yes, I noticed that. >>>> >>>>> Good to know there is no PPC32 any more. I always had to take >>>>> care I don't break anything in this 'invisible team mate' on Power :) >>>>> >>>>> Do you want me to make a new webrev with your edits? I'm >>>>> fine with the webrev you mailed around, though. I tested it to >>>>> work on ppc, and I'll run it through our tests tonight. >>>> You don't have to create a new webrev. If all testing passed and the other >>> reviewers agree with the latest webrev, you can send me a changeset and I'll >>> push it. >>>> Best regards, >>>> Tobias >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>>>>> Sent: Dienstag, 12. Juli 2016 14:34 >>>>>> To: Vladimir Kozlov ; Lindenmaier, Goetz >>>>>> ; hotspot-compiler- >>> dev at openjdk.java.net >>>>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>>>> dev at openjdk.java.net> >>>>>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>>>>> c1_LIR.hpp. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 06.07.2016 00:47, Vladimir Kozlov wrote: >>>>>>> CC to runtime too since it has changes in Interpreter and affects our >>> closed >>>>>> code. >>>>>>> Hi Goetz, >>>>>>> >>>>>>> Please, set "Fix Version". >>>>>>> >>>>>>> And if it is JDK 9 you need FC Extension Request since you converted it >>> to >>>>>> Enhancement: >>>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >>> June/004443.html >>>>>>> Someone from Oracle have to sponsor it and do related closed code >>>>>> changes and testing. >>>>>> >>>>>> webrev.03 looks good to me. I did the necessary closed changes (review >>> is >>>>>> pending) and also adapted some of the public code. >>>>>> >>>>>> Incremental webrev: >>>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ >>>>>> >>>>>> Full webrev: >>>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >>>>>> >>>>>> I removed the PPC code because since 8u33, SE Embedded releases no >>>>>> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM >>> specific >>>>>> code into the closed sources. I adapted the copyright dates and >>> refactored >>>>>> some related code. >>>>>> >>>>>> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks >>> for >>>>>> is_valid() which is false for fnoreg. We should check for >>>>>> 'as_FloatRegister(reg2) != fnoreg'. >>>>>> >>>>>> Tests are running. >>>>>> >>>>>> Best regards, >>>>>> Tobias >>>>>> >>>>>> [1] http://www.oracle.com/technetwork/java/embedded/embedded- >>>>>> se/downloads/index.html >>>>>> [2] http://www.oracle.com/technetwork/java/javase/certconfig- >>>>>> 2095354.html >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> could someone please have a look at this issue? I recap the >>> description >>>>>>>> below, and I also updated the webrev which would no more apply to >>>>>>>> hs-comp: >>>>>>>> >>>>>>>> c1_LIR.hpp defines a row of functions guarded by platform >>>>>>>> defines. This is bad style and hinders new platform ports. >>>>>>>> (I'm working on S390 aka Z :)) >>>>>>>> >>>>>>>> This change removes the majority of these defines. It introduces >>>>>>>> common headers, and moves implementations to c1_LIR_.cpp >>> files. >>>>>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>>>>>> This is not used in any openJdk platform. I can not test this >>>>>>>> on the closed platforms ARM32 and PPC32. >>>>>>>> >>>>>>>> It removes the guard around the LIR_Address constructor. There >>>>>>>> is no point in guarding this code, verify() assures by >>>>>>>> assertions that it can not be misused. I also introduce a new >>>>>>>> constructor that leaves out the scale argument and introduce >>>>>>>> some usages on X86. >>>>>>>> >>>>>>>> This change also moves verify() to the new platform files. In the >>>>>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>>>>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>>>>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>>>>>> >>>>>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>>>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>>>>>> it should be moved to according new files c1_LIR_.cpp in >>>>>>>> the closed ports. But this way the change should basically >>>>>>>> work for the closed ports. >>>>>>>> >>>>>>>> I added fnoreg on x86 to note down the code similarly on all >>>>>>>> platforms. >>>>>>>> >>>>>>>> I cleaned up a flag with a limited range on PPC_32. >>>>>>>> >>>>>>>> generate_stack_overflow_check() in >>> templateInterpreterGenerator.hpp >>>>>>>> is defined with different parameters for the platforms. I added default >>>>>>>> parameters noreg so that the signature is the same for all platforms. >>>>>>>> >>>>>>>> Please review this change. I please need a sponsor. >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- >>> simplifyC1/webrev.02/ >>>>>>>> I built and tested this on linuxx86_64, solaris_sparc and >>>>>>>> the ppc platforms. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> From tobias.hartmann at oracle.com Thu Jul 14 15:35:32 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Jul 2016 17:35:32 +0200 Subject: [ping] RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <7a6717e6-919d-77c7-f678-cea873f1ca88@oracle.com> References: <53ac409270bc43cbb9257c2a2f82311d@DEWDFE13DE09.global.corp.sap> <5784E3B8.40401@oracle.com> <309847e2a5414dc198b00db7c7528c2c@DEWDFE13DE09.global.corp.sap> <5784EB7A.3000608@oracle.com> <578728F6.2060306@oracle.com> <7921c3aa4efd40abb3755cff3d97b699@DEWDFE13DE09.global.corp.sap> <578730FF.1030208@oracle.com> <7a6717e6-919d-77c7-f678-cea873f1ca88@oracle.com> Message-ID: <5787B144.7080001@oracle.com> Hi Daniel, okay, thanks for the clarification! Best regards, Tobias On 14.07.2016 17:32, Daniel D. Daugherty wrote: > Vladimir H. has to approve the request as the Hotspot Group lead. > The next step is the JDK9 Release Team which discusses FC requests > on Thursdays so it should be today... After the Release Team approves, > Vladimir will set the 'jdk9-fc-yes' label. > > Dan > > > On 7/14/16 12:28 AM, Tobias Hartmann wrote: >> Hi Goetz, >> >> Vladimir K. already approved the request but I think he forgot to add the 'jdk9-fc-yes' label. Let's wait for him to do that. >> >> Best regards, >> Tobias >> >> On 14.07.2016 08:25, Lindenmaier, Goetz wrote: >>> Hi Tobias, >>> >>> don't we have to wait until the enhancement is accepted? >>> The bug still has tag jdk9-fc-request. >>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>>> Sent: Thursday, July 14, 2016 7:54 AM >>>> To: Lindenmaier, Goetz ; Vladimir Kozlov >>>> ; hotspot-compiler-dev at openjdk.java.net >>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>> dev at openjdk.java.net> >>>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>>> c1_LIR.hpp. >>>> >>>> Hi, >>>> >>>> all tests passed. If everyone's fine with the latest webrev, I'll push this >>>> tomorrow: >>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >>>> >>>> Goetz, could you please send me a changeset? >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 12.07.2016 15:07, Tobias Hartmann wrote: >>>>> Hi Goetz, >>>>> >>>>> On 12.07.2016 15:03, Lindenmaier, Goetz wrote: >>>>>> Hi Tobias, >>>>>> >>>>>> thanks for looking at this change! Your additional edits look good. >>>>>> Thanks for spotting the problems. Unfortunately, we don't have >>>>>> an aarch machine. >>>>> Sure, no problem! Actually, the 'fnoreg->encoding()' also showed up on >>>> SPARC. >>>>>> I also had problems with these asserts, as_FloatRegister(reg2) >>>>>> was not possible on ppc because it did not like the '-1'. But that's >>>>>> fixed already. >>>>> Yes, I noticed that. >>>>> >>>>>> Good to know there is no PPC32 any more. I always had to take >>>>>> care I don't break anything in this 'invisible team mate' on Power :) >>>>>> >>>>>> Do you want me to make a new webrev with your edits? I'm >>>>>> fine with the webrev you mailed around, though. I tested it to >>>>>> work on ppc, and I'll run it through our tests tonight. >>>>> You don't have to create a new webrev. If all testing passed and the other >>>> reviewers agree with the latest webrev, you can send me a changeset and I'll >>>> push it. >>>>> Best regards, >>>>> Tobias >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>>>>>> Sent: Dienstag, 12. Juli 2016 14:34 >>>>>>> To: Vladimir Kozlov ; Lindenmaier, Goetz >>>>>>> ; hotspot-compiler- >>>> dev at openjdk.java.net >>>>>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>>>>> dev at openjdk.java.net> >>>>>>> Subject: Re: [ping] RFR(M): 8160245: C1: Clean up platform #defines in >>>>>>> c1_LIR.hpp. >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> On 06.07.2016 00:47, Vladimir Kozlov wrote: >>>>>>>> CC to runtime too since it has changes in Interpreter and affects our >>>> closed >>>>>>> code. >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> Please, set "Fix Version". >>>>>>>> >>>>>>>> And if it is JDK 9 you need FC Extension Request since you converted it >>>> to >>>>>>> Enhancement: >>>>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >>>> June/004443.html >>>>>>>> Someone from Oracle have to sponsor it and do related closed code >>>>>>> changes and testing. >>>>>>> >>>>>>> webrev.03 looks good to me. I did the necessary closed changes (review >>>> is >>>>>>> pending) and also adapted some of the public code. >>>>>>> >>>>>>> Incremental webrev: >>>>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.incremental/ >>>>>>> >>>>>>> Full webrev: >>>>>>> http://cr.openjdk.java.net/~thartmann/8160245/webrev.00/ >>>>>>> >>>>>>> I removed the PPC code because since 8u33, SE Embedded releases no >>>>>>> longer include 32-bit PPC platforms (see [1], [2]) and moved the ARM >>>> specific >>>>>>> code into the closed sources. I adapted the copyright dates and >>>> refactored >>>>>>> some related code. >>>>>>> >>>>>>> Also, 'fnoreg->encoding()' fails because RegisterImpl::encoding() checks >>>> for >>>>>>> is_valid() which is false for fnoreg. We should check for >>>>>>> 'as_FloatRegister(reg2) != fnoreg'. >>>>>>> >>>>>>> Tests are running. >>>>>>> >>>>>>> Best regards, >>>>>>> Tobias >>>>>>> >>>>>>> [1] http://www.oracle.com/technetwork/java/embedded/embedded- >>>>>>> se/downloads/index.html >>>>>>> [2] http://www.oracle.com/technetwork/java/javase/certconfig- >>>>>>> 2095354.html >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 7/5/16 3:47 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could someone please have a look at this issue? I recap the >>>> description >>>>>>>>> below, and I also updated the webrev which would no more apply to >>>>>>>>> hs-comp: >>>>>>>>> >>>>>>>>> c1_LIR.hpp defines a row of functions guarded by platform >>>>>>>>> defines. This is bad style and hinders new platform ports. >>>>>>>>> (I'm working on S390 aka Z :)) >>>>>>>>> >>>>>>>>> This change removes the majority of these defines. It introduces >>>>>>>>> common headers, and moves implementations to c1_LIR_.cpp >>>> files. >>>>>>>>> It guards single_softfp() and double_softfp() by __SOFTFP__. >>>>>>>>> This is not used in any openJdk platform. I can not test this >>>>>>>>> on the closed platforms ARM32 and PPC32. >>>>>>>>> >>>>>>>>> It removes the guard around the LIR_Address constructor. There >>>>>>>>> is no point in guarding this code, verify() assures by >>>>>>>>> assertions that it can not be misused. I also introduce a new >>>>>>>>> constructor that leaves out the scale argument and introduce >>>>>>>>> some usages on X86. >>>>>>>>> >>>>>>>>> This change also moves verify() to the new platform files. In the >>>>>>>>> header, LIR_ADDRESS_PD_VERIFY was used to guard usage >>>>>>>>> of pd_verify(). Neither of these are used in openJdk. If this define >>>>>>>>> is used in the closed ports pd_verify() must be renamed to verify(). >>>>>>>>> >>>>>>>>> The code that was previously guarded by ARM, ARM32 or PPC32 is >>>>>>>>> moved to a properly guarded section in c1_LIR.cpp. Actually, >>>>>>>>> it should be moved to according new files c1_LIR_.cpp in >>>>>>>>> the closed ports. But this way the change should basically >>>>>>>>> work for the closed ports. >>>>>>>>> >>>>>>>>> I added fnoreg on x86 to note down the code similarly on all >>>>>>>>> platforms. >>>>>>>>> >>>>>>>>> I cleaned up a flag with a limited range on PPC_32. >>>>>>>>> >>>>>>>>> generate_stack_overflow_check() in >>>> templateInterpreterGenerator.hpp >>>>>>>>> is defined with different parameters for the platforms. I added default >>>>>>>>> parameters noreg so that the signature is the same for all platforms. >>>>>>>>> >>>>>>>>> Please review this change. I please need a sponsor. >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160245 >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8160245- >>>> simplifyC1/webrev.02/ >>>>>>>>> I built and tested this on linuxx86_64, solaris_sparc and >>>>>>>>> the ppc platforms. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> > From daniel.daugherty at oracle.com Thu Jul 14 15:41:44 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 09:41:44 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <578744D5.7060300@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> Message-ID: On 7/14/16 1:52 AM, Alan Burlison wrote: > On 14/07/2016 02:20, David Holmes wrote: > >> One query: if pwd.h is not the last file included don't we need to undef >> _POSIX_PTHREAD_SEMANTICS again to ensure no other included definitions >> are affected? If we don't need to do that then I wonder whether >> _POSIX_PTHREAD_SEMANTICS should not simply be set via the build system >> for all compilations? > > _POSIX_PTHREAD_SEMANTICS only affects a few APIs which changed between > POSIX.1c Draft 6 and POSIX 1003.1c - Solaris implemented the draft > version due to release scheduling issues, which was a mistake. Some of > the differences don't matter for LP64 apps such as Java, the other > APIs are less-frequently used. The main problems you tend to see are > the user/group iteration APIs (as in this case) and directory > enumeration. You could undef _POSIX_PTHREAD_SEMANTICS if you wanted > but there's no real benefit and it would add yet more clutter. If we #undef'ed it right after the one or two header files that we intend it to affect, then our intentions would be more clear. Yes, it will add one more line of "clutter", but I think clarity is more important. I also think this can be done as a pre-push change and does not need to go through yet another round of testing. Dan > > As for setting it globally, no that wouldn't be a good idea. It's a > workaround for a problem that will be gone in later Solaris releases, > where you'll get the POSIX 1003.1c definitions by default and will > have to explicitly ask for the old draft ones. At that point defining > _POSIX_PTHREAD_SEMANTICS will have no effect. It is a transitional > workaround for a misfeature and as such I believe needs to be > restricted as much as possible by just adding it to the affected > files, and then removing it altogether as soon as possible. > From Alan.Burlison at oracle.com Thu Jul 14 16:33:43 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 14 Jul 2016 17:33:43 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> Message-ID: <5787BEE7.4000501@oracle.com> On 14/07/2016 16:41, Daniel D. Daugherty wrote: > If we #undef'ed it right after the one or two header files that we intend > it to affect, then our intentions would be more clear. Yes, it will add > one more line of "clutter", but I think clarity is more important. I don't see how that makes intent any clearer when there's already a comment that says exactly why it is being defined: /* For POSIX-compliant getpwuid_r on Solaris */ #if defined(__solaris__) #define _POSIX_PTHREAD_SEMANTICS #endif #include And if it is properly guarded, as it is when it is defined, it needs 3 lines, not 1. The guards aren't strictly necessary, so this would suffice: /* For POSIX-compliant getpwuid_r on Solaris */ #define _POSIX_PTHREAD_SEMANTICS #include #undef _POSIX_PTHREAD_SEMANTICS Although I think this is verging on bikeshedding TBH. > I also think this can be done as a pre-push change and does not need to > go through yet another round of testing. -- Alan Burlison -- From daniel.daugherty at oracle.com Thu Jul 14 16:44:27 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 10:44:27 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5787BEE7.4000501@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <5787BEE7.4000501@oracle.com> Message-ID: On 7/14/16 10:33 AM, Alan Burlison wrote: > On 14/07/2016 16:41, Daniel D. Daugherty wrote: > >> If we #undef'ed it right after the one or two header files that we >> intend >> it to affect, then our intentions would be more clear. Yes, it will add >> one more line of "clutter", but I think clarity is more important. > > I don't see how that makes intent any clearer when there's already a > comment that says exactly why it is being defined: > > /* For POSIX-compliant getpwuid_r on Solaris */ > #if defined(__solaris__) > #define _POSIX_PTHREAD_SEMANTICS > #endif > #include > > And if it is properly guarded, as it is when it is defined, it needs 3 > lines, not 1. The guards aren't strictly necessary, so this would > suffice: > > /* For POSIX-compliant getpwuid_r on Solaris */ > #define _POSIX_PTHREAD_SEMANTICS > #include > #undef _POSIX_PTHREAD_SEMANTICS > > Although I think this is verging on bikeshedding TBH. The #undef line makes it clear that you wanted the define for pwd.h and only pwd.h. To me that's more clear, but I'm not going to insist. I'll leave it up to you and David H. to work out. Full disclosure: the sooner this review gets wrapped up, the sooner I can push the bits since I'm the sponsor. :-) Dan > >> I also think this can be done as a pre-push change and does not need to >> go through yet another round of testing. > From john.r.rose at oracle.com Thu Jul 14 16:48:01 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 14 Jul 2016 09:48:01 -0700 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> Message-ID: I really like this cleanup, especially the removal of variant 32/64 files (a long term aspiration) and of course the taming of that big blotch of ifdefs at the top of every file. The macrology must be made very clear. Comments should give several examples. I agree that the macro name should refer to concatenation. I trust someone can come up with the prettiest possible formulation, which isn't saying much; cpp code is no beauty pageant. Kudos, ? John > On Jul 14, 2016, at 1:49 AM, Lindenmaier, Goetz wrote: > > this change simplifies the include cascades used to include > > platform headers. From Alan.Burlison at oracle.com Thu Jul 14 16:52:15 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 14 Jul 2016 17:52:15 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <5787BEE7.4000501@oracle.com> Message-ID: <5787C33F.3020903@oracle.com> On 14/07/2016 17:44, Daniel D. Daugherty wrote: > The #undef line makes it clear that you wanted the define for > pwd.h and only pwd.h. To me that's more clear, but I'm not > going to insist. > > I'll leave it up to you and David H. to work out. > > Full disclosure: the sooner this review gets wrapped up, the > sooner I can push the bits since I'm the sponsor. :-) I think the unguarded #define/#undef is fine if you want to avoid clutter but I don't have any strong opinion, as long as the macro is defined before the pwd.g or grp.h files are included it will do the job. -- Alan Burlison -- From kim.barrett at oracle.com Thu Jul 14 17:19:21 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Jul 2016 13:19:21 -0400 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> Message-ID: > On Jul 14, 2016, at 8:42 AM, Lindenmaier, Goetz wrote: > > Hi Andrew, > > unfortunately it's not that simple ... > It does not grok the macro INCLUDE_SUFFIX_CPU, nor the dot in .hpp: > > #define CONCAT4(a, b, c, d) a ## b ## c ## d > #define xcpu_header(x, y) XSTR(CONCAT4(x, _, INCLUDE_SUFFIX_CPU, y)) > #define cpu_header(basename) xcpu_header(basename,.hpp) > cpu_header(globalDefinitions) > > error: pasting "globalDefinitions_INCLUDE_SUFFIX_CPU" and "." does not give a valid preprocessing token I think part of what you want is called PASTE_TOKENS in macros.hpp. The ?.? might be a significant impediment though. I need to think about that one. Note that we can?t make use PP string concatenation here to include a period. But stringification operates on expressions, so maybe don?t try to paste the file type, instead just including it directly in the token stream. But that might run into whitespace problems if not careful. From kim.barrett at oracle.com Thu Jul 14 17:43:00 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Jul 2016 13:43:00 -0400 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> Message-ID: > On Jul 14, 2016, at 1:19 PM, Kim Barrett wrote: > >> On Jul 14, 2016, at 8:42 AM, Lindenmaier, Goetz wrote: >> >> Hi Andrew, >> >> unfortunately it's not that simple ... >> It does not grok the macro INCLUDE_SUFFIX_CPU, nor the dot in .hpp: >> >> #define CONCAT4(a, b, c, d) a ## b ## c ## d >> #define xcpu_header(x, y) XSTR(CONCAT4(x, _, INCLUDE_SUFFIX_CPU, y)) >> #define cpu_header(basename) xcpu_header(basename,.hpp) >> cpu_header(globalDefinitions) >> >> error: pasting "globalDefinitions_INCLUDE_SUFFIX_CPU" and "." does not give a valid preprocessing token > > I think part of what you want is called PASTE_TOKENS in macros.hpp. > > The ?.? might be a significant impediment though. I need to think about that one. > > Note that we can?t make use PP string concatenation here to include a period. > But stringification operates on expressions, so maybe don?t try to paste the file type, > instead just including it directly in the token stream. But that might run into whitespace > problems if not careful. But looking more closely at what?s being discussed and interpolating a bit (I seem to be missing some messages in this thread for some reason?), I think token pasting doesn?t work for the suffix part of this, because we?re dealing with something that is not syntactically an identifier. The original approach seems okay to me, modulo the name SUB (or even HSSUB). If token pasting were used to construct the stem and the suffix is expanded using this substitution macro, then there?s generally only one occurrence of it and its length no longer matters much. Stringizing is fine with any expression. Just need to be careful not to inadvertently insert any whitespace into the mix. From jiangli.zhou at oracle.com Thu Jul 14 17:51:16 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 14 Jul 2016 10:51:16 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <578789CF.3050902@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> <578789CF.3050902@oracle.com> Message-ID: <182F8086-22C0-48B7-A842-74094D3F3957@oracle.com> Hi Ioi, > On Jul 14, 2016, at 5:47 AM, Ioi Lam wrote: > > Hi Jiangli, > > I think these are not necessary in systemDictionary.cpp, as the same condition is checked in the "inner" load_share_class() function. > > 1249 // Don't load shared class when JvmtiExport::should_post_class_file_load_hook() > 1250 // is enabled since posting CFLH is not supported when loading shared class. > 1251 if (!JvmtiExport::should_post_class_file_load_hook()) { I think it is safer to have the check here also, so we don?t do find_shared_class(). > > The rest looks OK to me. Thanks for the review! Thanks, Jiangli > > Thanks > - Ioi > > On 7/13/16 5:06 PM, Jiangli Zhou wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ >> >> Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). >> Agent specified via command line: >> With -Xshare:on, report error and exit. >> Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. >> With -Xshare:auto, disallow loading shared class >> If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). >> If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). >> Agent is attached: >> With -Xshare:on and -Xshare:auto >> Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. >> Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the >> 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. >> >> Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. >> >> Thanks, >> Jiangli >> >> >> >>> On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: >>> >>> Hi Ioi, >>> >>>> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >>>> >>>> Hi Jiangli, >>>> >>>> I agree what what Karen has said. >>>> >>>> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >>>> >>>> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. >>> Agreed. >>> >>>> Also, maybe this check can also be removed? >>>> >>>> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >>>> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >>>> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >>>> >>>> Since the same check is already done in the "inner" load_shared_class() method. >>> I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. >>> >>> Thanks, >>> Jiangli >>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>>>> Hi Karen, >>>>> >>>>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>>>> >>>>>> Jiangli, >>>>>> >>>>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>>>> >>>>>> I agree with not quitting the vm on agent attach. >>>>>> I actually think we also want the agent attach to succeed - see below. >>>>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>>>> >>>>>>> (Adding serviceability-dev at openjdk.java.net) >>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> I think the two blocks of >>>>>>> >>>>>>> if (RequireSharedSpaces) { >>>>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>>>> vm_exit(1); >>>>>>> } >>>>>>> >>>>>>> should be removed. >>>>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>>>> but no forcing of using the shared spaces if there is an agent. >>>>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>>>> Totally agree - we should not quit the VM. >>>>>> >>>>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>>>> >>>>>>> jvmtiError >>>>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>>>> >>>>>>> ... >>>>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>>>> + } >>>>>>> record_class_file_load_hook_enabled(); >>>>>>> } >>>>>>> ? >>>>>>> } >>>>>>> >>>>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>>>> Thanks >>>>>>> - Ioi >>>>>> Jiangli: >>>>>> >>>>>> Minor code review comments: >>>>>> >>>>>> metaspace.cpp line 3181: CFHL-> CFLH >>>>>> >>>>>> metaspace.cpp: >>>>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>>> >>>>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>>>> bug: JDK-8141341 >>>>>>>> >>>>>>>> With -Xshare:on >>>>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>>>> >>>>>>>> With -Xshare:auto >>>>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>>>> >>>>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jiangli >>>>>>>> >>>>>>>> > From ivan.gerasimov at oracle.com Thu Jul 14 18:46:19 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Jul 2016 21:46:19 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> Message-ID: <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> Thank you David for looking into this! Here's the webrev updated in accordance with your and Daniel's suggestions: http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Please see my answers inline > Nit: can we change 'registered_itself" to just "registered" please. Done. > > Can you explain under what conditions a thread will now reach the > self-suspension code. Is that only if an error occurred such that we > were unable to register our handle for the process-exiting thread to > wait on? If so some commentary on that block seems appropriate - > perhaps more appropriate there than back up at the place where it > failed to get the handle (as Dan requested). > There are three kinds of threads, which can be caught in that self-suspension loop: 1) All threads that want to end (by calling _endthreadex()) *after* some process-exiting thread raised the flag `process_exiting`. The rationale here is that we know that the whole process is going to be terminated quite soon, so we do not allow any thread to call _endthreadex(), which seems to have the concurrency bug. 2) Any thread that wants to end the whole process, after some other thread raised the flag `process_exiting`. If more than one threads want to end the process, we let to do it only the thread that could raise the flag `process_exiting`. All other such threads will have to suspend themselves. 3) (Unlikely to happen in practice) Any thread that wants to end by calling _endthreadex(), but which failed to register itself due to failure of DuplicateHandle(). Here we still have a race, which can result in a wrong exit code of the process. > Given we keep missing conditions I'm only cautiously optimistic about > this. > And I'd like to understand how we still sometimes end up exiting with > an "error code" that seems to be the value of an exception! :( The last time the sentinel exit code =20115 was reported almost a year ago. After that the fix for JDK-8145127 had gone in, and I didn't see any more reports about wrong exit codes since then. In particular, that fix worked around the situation when more than one threads concurrently call System.exit(), which might have caused a race. With kind regards, Ivan > > Thanks, > David > >> With kind regards, >> Ivan >> > From goetz.lindenmaier at sap.com Thu Jul 14 19:18:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 19:18:35 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> Message-ID: Hi everybody, please take into account that these macros are only used within 20 lines of the file macro.hpp. The code everybody needs to understand is #include cpu_header(bytes) which, in this example, is in file bytes.hpp and expands to bytes_.hpp. There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. I really would appreciate if I don't have to spend days editing the 12 lines that use SUB(). @Kim I'm working on the s390 port, and posted my current progress claiming that the biggest shared change I need to do is adding the #includes. http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023782.html This arose the discussion about the includes. Later I posted a prototype of what Volker proposed in that discussion to that thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023934.html which I now turned into a RFR. Best regards, Goetz. > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Thursday, July 14, 2016 7:43 PM > To: Lindenmaier, Goetz > Cc: Andrew Haley ; hotspot-compiler- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > > On Jul 14, 2016, at 1:19 PM, Kim Barrett wrote: > > > >> On Jul 14, 2016, at 8:42 AM, Lindenmaier, Goetz > wrote: > >> > >> Hi Andrew, > >> > >> unfortunately it's not that simple ... > >> It does not grok the macro INCLUDE_SUFFIX_CPU, nor the dot in .hpp: > >> > >> #define CONCAT4(a, b, c, d) a ## b ## c ## d > >> #define xcpu_header(x, y) XSTR(CONCAT4(x, _, INCLUDE_SUFFIX_CPU, > y)) > >> #define cpu_header(basename) xcpu_header(basename,.hpp) > >> cpu_header(globalDefinitions) > >> > >> error: pasting "globalDefinitions_INCLUDE_SUFFIX_CPU" and "." does not > give a valid preprocessing token > > > > I think part of what you want is called PASTE_TOKENS in macros.hpp. > > > > The ?.? might be a significant impediment though. I need to think about > that one. > > > > Note that we can?t make use PP string concatenation here to include a > period. > > But stringification operates on expressions, so maybe don?t try to paste the > file type, > > instead just including it directly in the token stream. But that might run into > whitespace > > problems if not careful. > > But looking more closely at what?s being discussed and interpolating a bit (I > seem to be > missing some messages in this thread for some reason?), I think token > pasting doesn?t > work for the suffix part of this, because we?re dealing with something that is > not syntactically > an identifier. > > The original approach seems okay to me, modulo the name SUB (or even > HSSUB). > If token pasting were used to construct the stem and the suffix is expanded > using this > substitution macro, then there?s generally only one occurrence of it and its > length no > longer matters much. > > Stringizing is fine with any expression. Just need to be careful not to > inadvertently > insert any whitespace into the mix. From kim.barrett at oracle.com Thu Jul 14 21:19:32 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Jul 2016 17:19:32 -0400 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> Message-ID: > On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz wrote: > > Hi everybody, > > please take into account that these macros are only used within 20 lines of > the file macro.hpp. The code everybody needs to understand is > #include cpu_header(bytes) > which, in this example, is in file bytes.hpp and expands to bytes_.hpp. > There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > > I really would appreciate if I don't have to spend days editing the > 12 lines that use SUB(). > > @Kim > I'm working on the s390 port, and posted my current progress claiming > that the biggest shared change I need to do is adding the #includes. > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023782.html > This arose the discussion about the includes. > Later I posted a prototype of what Volker proposed in that discussion > to that thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023934.html > which I now turned into a RFR. Thanks. I think I see what happened to the email thread for me; it looks like one of Andrew?s replies went to hotspot-compiler-dev but not hotspot-runtime-dev, and I was not subscribed to the compiler list this morning. I like the idea, just quibbling over details. I've only reviewed macros.hpp so far; the rest looks like it can wait until the details are settled. ------------------------------------------------------------------------------ src/share/vm/utilities/macros.hpp 470 // Helper macros to workaround existing #defines that spoil 471 // the macro expansion. Detected so far: linux=1, sparc=1. This issue can be dodged by making the leading underscore part of the expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, use instead 66 JVM_CFLAGS_TARGET_DEFINES += \ 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ Note the insertion of leading "_" for the values. Then the whole macro block can be written as #define cpu_header_stem(basename) PASTE_TOKENS(basename, INCLUDE_SUFFIX_CPU) #define os_header_stem(basename) PASTE_TOKENS(basename, INCLUDE_SUFFIX_OS) #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) #define cpu_header(basename) XSTR(cpu_header_stem(basename).hpp) #define cpu_header_inline(basename) XSTR(cpu_header_stem(basename).inline.hpp) #define os_header(basename) XSTR(os_header_stem(basename).hpp) #define os_header_inline(basename) XSTR(os_header_stem(basename).inline.hpp) #define os_cpu_header(basename) XSTR(os_cpu_header_stem(basename).hpp) #define os_cpu_header_inline(basename) XSTR(os_cpu_header_stem(basename).inline.hpp) And SUB is no longer used... If some future build system wants brackets instead of strings, just replace XSTR(...) with <...>. We lose if _linux or _sparc (for example) are defined, but that's true for the webrev.01 code too. But note that underscore followed by a lowercase letter is not in the reserved word pattern for C/C++. BTW, my preference would be to use uppercase for the macro names. I don't know what others think about that. ------------------------------------------------------------------------------ From daniel.daugherty at oracle.com Thu Jul 14 21:31:12 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 15:31:12 -0600 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> Message-ID: <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> On 7/14/16 12:46 PM, Ivan Gerasimov wrote: > Thank you David for looking into this! > > Here's the webrev updated in accordance with your and Daniel's > suggestions: > http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ src/os/windows/vm/os_windows.cpp L3900: bool registered = false; Please consider adding a comment above this variable: // We only attempt to register threads until a process exiting // thread manages to set the process_exiting flag. Any threads // that come through here after the process_exiting flag is set // are unregistered and will be caught in the SuspendThread() // infinite loop below. My request is different than David's. I prefer the comment up here by the 'registered' variable because that variable is key for getting into the SuspendThread() infinite loop. The comment also occurs before all the code paths that you have trace out with the different Ept types and flags states. I'm really hoping that this is the last tweak we need to make to clearly comment what we're doing to alleviate this OS race. The number of occurrences of the underlying bug keep going down with every iteration so we're getting close. Dan > > Please see my answers inline > > >> Nit: can we change 'registered_itself" to just "registered" please. > Done. > >> >> Can you explain under what conditions a thread will now reach the >> self-suspension code. Is that only if an error occurred such that we >> were unable to register our handle for the process-exiting thread to >> wait on? If so some commentary on that block seems appropriate - >> perhaps more appropriate there than back up at the place where it >> failed to get the handle (as Dan requested). >> > There are three kinds of threads, which can be caught in that > self-suspension loop: > 1) All threads that want to end (by calling _endthreadex()) *after* > some process-exiting thread raised the flag `process_exiting`. > The rationale here is that we know that the whole process is going to > be terminated quite soon, so we do not allow any thread to call > _endthreadex(), which seems to have the concurrency bug. > 2) Any thread that wants to end the whole process, after some other > thread raised the flag `process_exiting`. > If more than one threads want to end the process, we let to do it only > the thread that could raise the flag `process_exiting`. All other > such threads will have to suspend themselves. > 3) (Unlikely to happen in practice) Any thread that wants to end by > calling _endthreadex(), but which failed to register itself due to > failure of DuplicateHandle(). > Here we still have a race, which can result in a wrong exit code of > the process. > >> Given we keep missing conditions I'm only cautiously optimistic about >> this. >> And I'd like to understand how we still sometimes end up exiting with >> an "error code" that seems to be the value of an exception! :( > > The last time the sentinel exit code =20115 was reported almost a year > ago. > After that the fix for JDK-8145127 had gone in, and I didn't see any > more reports about wrong exit codes since then. > In particular, that fix worked around the situation when more than one > threads concurrently call System.exit(), which might have caused a race. > > With kind regards, > Ivan > >> >> Thanks, >> David >> >>> With kind regards, >>> Ivan >>> >> > From cthalinger at twitter.com Thu Jul 14 22:39:50 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 14 Jul 2016 12:39:50 -1000 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED In-Reply-To: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> References: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> Message-ID: <9E968184-EE4E-46BA-B3B4-345A43E9F974@twitter.com> > On Jul 13, 2016, at 6:26 PM, David Holmes wrote: > > The bug report for this is confidential but quite simply all of the little tweaks and knobs we added to the open build and source files to support the Java SE Embedded product no longer need to be there for JDK 9. A lot of this has already been addressed in relation to other changes (eg. new hotspot build), but this cleans out the rest. > > webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ src/share/vm/runtime/globals.hpp + range(0, max_jint) \ Should be indented, I think. Otherwise this looks good and I?m glad it?s gone. > > There are related JDK changes being handled in a separate review thread. If you like you can see them all: > > http://cr.openjdk.java.net/~dholmes/8140723/ > > Thanks, > David From ivan.gerasimov at oracle.com Thu Jul 14 22:57:22 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Jul 2016 01:57:22 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> Message-ID: <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> Hey! I've updated the webrev in place at http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ On 15.07.2016 0:31, Daniel D. Daugherty wrote: > On 7/14/16 12:46 PM, Ivan Gerasimov wrote: >> Thank you David for looking into this! >> >> Here's the webrev updated in accordance with your and Daniel's >> suggestions: >> http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ > > src/os/windows/vm/os_windows.cpp > L3900: bool registered = false; > Please consider adding a comment above this variable: > > // We only attempt to register threads until a process exiting > // thread manages to set the process_exiting flag. Any threads > // that come through here after the process_exiting flag is set > // are unregistered and will be caught in the SuspendThread() > // infinite loop below. > Sure. Added this comment. > My request is different than David's. I prefer the comment up > here by the 'registered' variable because that variable is > key for getting into the SuspendThread() infinite loop. The > comment also occurs before all the code paths that you have > trace out with the different Ept types and flags states. > > I'm really hoping that this is the last tweak we need to make to > clearly comment what we're doing to alleviate this OS race. > The number of occurrences of the underlying bug keep going down > with every iteration so we're getting close. > Yes. This is my hope too. With kind regards, Ivan From daniel.daugherty at oracle.com Thu Jul 14 23:01:53 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 17:01:53 -0600 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> Message-ID: <81e46d34-a40a-421f-0fed-fe825999e91c@oracle.com> On 7/14/16 4:57 PM, Ivan Gerasimov wrote: > Hey! > > I've updated the webrev in place at > http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Thumbs up! Dan > > On 15.07.2016 0:31, Daniel D. Daugherty wrote: >> On 7/14/16 12:46 PM, Ivan Gerasimov wrote: >>> Thank you David for looking into this! >>> >>> Here's the webrev updated in accordance with your and Daniel's >>> suggestions: >>> http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> L3900: bool registered = false; >> Please consider adding a comment above this variable: >> >> // We only attempt to register threads until a process exiting >> // thread manages to set the process_exiting flag. Any threads >> // that come through here after the process_exiting flag is set >> // are unregistered and will be caught in the SuspendThread() >> // infinite loop below. >> > Sure. Added this comment. > >> My request is different than David's. I prefer the comment up >> here by the 'registered' variable because that variable is >> key for getting into the SuspendThread() infinite loop. The >> comment also occurs before all the code paths that you have >> trace out with the different Ept types and flags states. >> >> I'm really hoping that this is the last tweak we need to make to >> clearly comment what we're doing to alleviate this OS race. >> The number of occurrences of the underlying bug keep going down >> with every iteration so we're getting close. >> > Yes. This is my hope too. > > With kind regards, > Ivan > From david.holmes at oracle.com Fri Jul 15 03:13:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 13:13:18 +1000 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> Message-ID: <13836979-c602-bc80-1af4-ef2a2bf5bef4@oracle.com> On 15/07/2016 8:57 AM, Ivan Gerasimov wrote: > Hey! > > I've updated the webrev in place at > http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Thanks Ivan - looks good. See also: https://bugs.openjdk.java.net/browse/JDK-8160596 https://bugs.openjdk.java.net/browse/JDK-8079441 regarding strange exit code values being seen. David > On 15.07.2016 0:31, Daniel D. Daugherty wrote: >> On 7/14/16 12:46 PM, Ivan Gerasimov wrote: >>> Thank you David for looking into this! >>> >>> Here's the webrev updated in accordance with your and Daniel's >>> suggestions: >>> http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> L3900: bool registered = false; >> Please consider adding a comment above this variable: >> >> // We only attempt to register threads until a process exiting >> // thread manages to set the process_exiting flag. Any threads >> // that come through here after the process_exiting flag is set >> // are unregistered and will be caught in the SuspendThread() >> // infinite loop below. >> > Sure. Added this comment. > >> My request is different than David's. I prefer the comment up >> here by the 'registered' variable because that variable is >> key for getting into the SuspendThread() infinite loop. The >> comment also occurs before all the code paths that you have >> trace out with the different Ept types and flags states. >> >> I'm really hoping that this is the last tweak we need to make to >> clearly comment what we're doing to alleviate this OS race. >> The number of occurrences of the underlying bug keep going down >> with every iteration so we're getting close. >> > Yes. This is my hope too. > > With kind regards, > Ivan > From david.holmes at oracle.com Fri Jul 15 05:06:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 15:06:47 +1000 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED In-Reply-To: <9E968184-EE4E-46BA-B3B4-345A43E9F974@twitter.com> References: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> <9E968184-EE4E-46BA-B3B4-345A43E9F974@twitter.com> Message-ID: <48ea4544-54f9-f012-6319-89ec15c0c912@oracle.com> On 15/07/2016 8:39 AM, Christian Thalinger wrote: > >> On Jul 13, 2016, at 6:26 PM, David Holmes > > wrote: >> >> The bug report for this is confidential but quite simply all of the >> little tweaks and knobs we added to the open build and source files to >> support the Java SE Embedded product no longer need to be there for >> JDK 9. A lot of this has already been addressed in relation to other >> changes (eg. new hotspot build), but this cleans out the rest. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ > > > src/share/vm/runtime/globals.hpp > > + range(0, max_jint) \ > > > Should be indented, I think. Fixed - webrev updated in place. > Otherwise this looks good and I?m glad it?s gone. Thanks for the review Christian! David ----- >> >> There are related JDK changes being handled in a separate review >> thread. If you like you can see them all: >> >> http://cr.openjdk.java.net/~dholmes/8140723/ >> >> Thanks, >> David > From david.holmes at oracle.com Fri Jul 15 06:28:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 16:28:55 +1000 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <578744D5.7060300@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> Message-ID: <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> Hi Alan, tl;dr: reviewed as-is More inline ... On 14/07/2016 5:52 PM, Alan Burlison wrote: > On 14/07/2016 02:20, David Holmes wrote: > >> One query: if pwd.h is not the last file included don't we need to undef >> _POSIX_PTHREAD_SEMANTICS again to ensure no other included definitions >> are affected? If we don't need to do that then I wonder whether >> _POSIX_PTHREAD_SEMANTICS should not simply be set via the build system >> for all compilations? > > _POSIX_PTHREAD_SEMANTICS only affects a few APIs which changed between > POSIX.1c Draft 6 and POSIX 1003.1c - Solaris implemented the draft > version due to release scheduling issues, which was a mistake. Some of > the differences don't matter for LP64 apps such as Java, the other APIs > are less-frequently used. The main problems you tend to see are the > user/group iteration APIs (as in this case) and directory enumeration. > You could undef _POSIX_PTHREAD_SEMANTICS if you wanted but there's no > real benefit and it would add yet more clutter. Okay I looked further into the affect of this (I recalled we also use it in a test to deal with a sigwait API issue) and see that it changes the form of the function prototypes (and underlying implementation) so it won't silently change anything. > As for setting it globally, no that wouldn't be a good idea. It's a > workaround for a problem that will be gone in later Solaris releases, > where you'll get the POSIX 1003.1c definitions by default and will have > to explicitly ask for the old draft ones. At that point defining > _POSIX_PTHREAD_SEMANTICS will have no effect. It is a transitional > workaround for a misfeature and as such I believe needs to be restricted > as much as possible by just adding it to the affected files, and then > removing it altogether as soon as possible. Looking further into this aspect I can't help but feel we should be defining: _POSIX_C_SOURCE=200112L which would also fix the current problem and more generally make it clear we are intending to use specific standard-based API's. But that is going somewhat further than the scope of the current fix - and may run into unexpected consequences (we've been somewhat lax at programming to specific language and API versions). So I'm okay with the fix as it stands. Thanks, David From goetz.lindenmaier at sap.com Fri Jul 15 07:30:00 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Jul 2016 07:30:00 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> Message-ID: <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> HI Kim, thanks for this version of the macros, it's working on all the platforms I can build. Actually, I would prefer having the '_' in the macros and not on the command line. This way, parts of the name construction are in CompileJvm.gmk, other parts are in macros.hpp. But constructing the search path is also in the makefile, and uses the very same string as the file suffixes. (Without '_', one could include that in the macro, too.) But overall, I consider this a detail and am as fine with your solution as with the SUB() macros. What is better is that the linux=1 etc problems are avoided. Any more opinions whether the macros should be upper case? Best regards, Goetz. > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Donnerstag, 14. Juli 2016 23:20 > To: Lindenmaier, Goetz > Cc: Andrew Haley ; hotspot-compiler- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > > On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > wrote: > > > > Hi everybody, > > > > please take into account that these macros are only used within 20 lines of > > the file macro.hpp. The code everybody needs to understand is > > #include cpu_header(bytes) > > which, in this example, is in file bytes.hpp and expands to > bytes_.hpp. > > There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > > > > I really would appreciate if I don't have to spend days editing the > > 12 lines that use SUB(). > > > > @Kim > > I'm working on the s390 port, and posted my current progress claiming > > that the biggest shared change I need to do is adding the #includes. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > July/023782.html > > This arose the discussion about the includes. > > Later I posted a prototype of what Volker proposed in that discussion > > to that thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > July/023934.html > > which I now turned into a RFR. > > Thanks. > > I think I see what happened to the email thread for me; it looks like one of > Andrew?s replies went to hotspot-compiler-dev but not hotspot-runtime- > dev, > and I was not subscribed to the compiler list this morning. > > I like the idea, just quibbling over details. I've only reviewed > macros.hpp so far; the rest looks like it can wait until the details > are settled. > > ------------------------------------------------------------------------------ > src/share/vm/utilities/macros.hpp > 470 // Helper macros to workaround existing #defines that spoil > 471 // the macro expansion. Detected so far: linux=1, sparc=1. > > This issue can be dodged by making the leading underscore part of the > expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, use > instead > > 66 JVM_CFLAGS_TARGET_DEFINES += \ > 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ > > Note the insertion of leading "_" for the values. > > Then the whole macro block can be written as > > #define cpu_header_stem(basename) PASTE_TOKENS(basename, > INCLUDE_SUFFIX_CPU) > #define os_header_stem(basename) PASTE_TOKENS(basename, > INCLUDE_SUFFIX_OS) > #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, > PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > > #define cpu_header(basename) XSTR(cpu_header_stem(basename).hpp) > #define cpu_header_inline(basename) > XSTR(cpu_header_stem(basename).inline.hpp) > #define os_header(basename) XSTR(os_header_stem(basename).hpp) > #define os_header_inline(basename) > XSTR(os_header_stem(basename).inline.hpp) > #define os_cpu_header(basename) > XSTR(os_cpu_header_stem(basename).hpp) > #define os_cpu_header_inline(basename) > XSTR(os_cpu_header_stem(basename).inline.hpp) > > And SUB is no longer used... > > If some future build system wants brackets instead of strings, just > replace XSTR(...) with <...>. > > We lose if _linux or _sparc (for example) are defined, but that's true > for the webrev.01 code too. But note that underscore followed by a > lowercase letter is not in the reserved word pattern for C/C++. > > BTW, my preference would be to use uppercase for the macro names. I > don't know what others think about that. > > ------------------------------------------------------------------------------ From david.holmes at oracle.com Fri Jul 15 09:11:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 19:11:16 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > HI Kim, > > thanks for this version of the macros, it's working on all the platforms > I can build. > > Actually, I would prefer having the '_' in the macros and not on the > command line. This way, parts of the name construction are in > CompileJvm.gmk, other parts are in macros.hpp. But constructing > the search path is also in the makefile, and uses the very same string > as the file suffixes. (Without '_', one could include that in the macro, too.) > > But overall, I consider this a detail and am as fine with your solution > as with the SUB() macros. What is better is that the linux=1 etc > problems are avoided. > > Any more opinions whether the macros should be upper case? Yeah they probably should be. Thanks, David > Best regards, > Goetz. > > >> -----Original Message----- >> From: Kim Barrett [mailto:kim.barrett at oracle.com] >> Sent: Donnerstag, 14. Juli 2016 23:20 >> To: Lindenmaier, Goetz >> Cc: Andrew Haley ; hotspot-compiler- >> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >> wrote: >>> >>> Hi everybody, >>> >>> please take into account that these macros are only used within 20 lines of >>> the file macro.hpp. The code everybody needs to understand is >>> #include cpu_header(bytes) >>> which, in this example, is in file bytes.hpp and expands to >> bytes_.hpp. >>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>> >>> I really would appreciate if I don't have to spend days editing the >>> 12 lines that use SUB(). >>> >>> @Kim >>> I'm working on the s390 port, and posted my current progress claiming >>> that the biggest shared change I need to do is adding the #includes. >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >> July/023782.html >>> This arose the discussion about the includes. >>> Later I posted a prototype of what Volker proposed in that discussion >>> to that thread: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >> July/023934.html >>> which I now turned into a RFR. >> >> Thanks. >> >> I think I see what happened to the email thread for me; it looks like one of >> Andrew?s replies went to hotspot-compiler-dev but not hotspot-runtime- >> dev, >> and I was not subscribed to the compiler list this morning. >> >> I like the idea, just quibbling over details. I've only reviewed >> macros.hpp so far; the rest looks like it can wait until the details >> are settled. >> >> ------------------------------------------------------------------------------ >> src/share/vm/utilities/macros.hpp >> 470 // Helper macros to workaround existing #defines that spoil >> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >> >> This issue can be dodged by making the leading underscore part of the >> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, use >> instead >> >> 66 JVM_CFLAGS_TARGET_DEFINES += \ >> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ >> >> Note the insertion of leading "_" for the values. >> >> Then the whole macro block can be written as >> >> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >> INCLUDE_SUFFIX_CPU) >> #define os_header_stem(basename) PASTE_TOKENS(basename, >> INCLUDE_SUFFIX_OS) >> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, >> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >> >> #define cpu_header(basename) XSTR(cpu_header_stem(basename).hpp) >> #define cpu_header_inline(basename) >> XSTR(cpu_header_stem(basename).inline.hpp) >> #define os_header(basename) XSTR(os_header_stem(basename).hpp) >> #define os_header_inline(basename) >> XSTR(os_header_stem(basename).inline.hpp) >> #define os_cpu_header(basename) >> XSTR(os_cpu_header_stem(basename).hpp) >> #define os_cpu_header_inline(basename) >> XSTR(os_cpu_header_stem(basename).inline.hpp) >> >> And SUB is no longer used... >> >> If some future build system wants brackets instead of strings, just >> replace XSTR(...) with <...>. >> >> We lose if _linux or _sparc (for example) are defined, but that's true >> for the webrev.01 code too. But note that underscore followed by a >> lowercase letter is not in the reserved word pattern for C/C++. >> >> BTW, my preference would be to use uppercase for the macro names. I >> don't know what others think about that. >> >> ------------------------------------------------------------------------------ > From Alan.Burlison at oracle.com Fri Jul 15 10:52:54 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 15 Jul 2016 11:52:54 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> Message-ID: <5788C086.6050509@oracle.com> On 15/07/2016 07:28, David Holmes wrote: > Okay I looked further into the affect of this (I recalled we also use it > in a test to deal with a sigwait API issue) and see that it changes the > form of the function prototypes (and underlying implementation) so it > won't silently change anything. Yes, that's another one of the places it is used and for that and other places it changes the APIs provided from the draft ones to the standards-conforming ones. This is all the result of decision made back in Solaris 2.4 that we are still living with, although it will be addressed in future releases. > Looking further into this aspect I can't help but feel we should be > defining: > > _POSIX_C_SOURCE=200112L > > which would also fix the current problem and more generally make it > clear we are intending to use specific standard-based API's. But that is > going somewhat further than the scope of the current fix - and may run > into unexpected consequences (we've been somewhat lax at programming to > specific language and API versions). Actually you almost certainly don't want that. Asking for a specific POSIX version means exactly that, you'll get the APIs defined in that version and nothing else. If you are using non-POSIX APIs, they will disappear, because what you are asking for is an environment which all conforming POSIX implementations will provide, i.e. lowest common denominator. The implementation in the header files doesn't always match up with that 100%, but that's theoretically how it should work. My general advice would be to set the smallest possible number of most restricted-scope feature macros that you can to get the behaviour you want, which in this case is _POSIX_PTHREAD_SEMANTICS. -- Alan Burlison -- From goetz.lindenmaier at sap.com Fri Jul 15 12:17:53 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Jul 2016 12:17:53 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: Hi, I made a new webrev: - '_' is added in makefile - uses Kim's macros - macros are capitalized - more comments in macros.hpp http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 15. Juli 2016 11:11 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > > HI Kim, > > > > thanks for this version of the macros, it's working on all the platforms > > I can build. > > > > Actually, I would prefer having the '_' in the macros and not on the > > command line. This way, parts of the name construction are in > > CompileJvm.gmk, other parts are in macros.hpp. But constructing > > the search path is also in the makefile, and uses the very same string > > as the file suffixes. (Without '_', one could include that in the macro, too.) > > > > But overall, I consider this a detail and am as fine with your solution > > as with the SUB() macros. What is better is that the linux=1 etc > > problems are avoided. > > > > Any more opinions whether the macros should be upper case? > > Yeah they probably should be. > > Thanks, > David > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >> Sent: Donnerstag, 14. Juli 2016 23:20 > >> To: Lindenmaier, Goetz > >> Cc: Andrew Haley ; hotspot-compiler- > >> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >> wrote: > >>> > >>> Hi everybody, > >>> > >>> please take into account that these macros are only used within 20 lines > of > >>> the file macro.hpp. The code everybody needs to understand is > >>> #include cpu_header(bytes) > >>> which, in this example, is in file bytes.hpp and expands to > >> bytes_.hpp. > >>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > >>> > >>> I really would appreciate if I don't have to spend days editing the > >>> 12 lines that use SUB(). > >>> > >>> @Kim > >>> I'm working on the s390 port, and posted my current progress claiming > >>> that the biggest shared change I need to do is adding the #includes. > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >> July/023782.html > >>> This arose the discussion about the includes. > >>> Later I posted a prototype of what Volker proposed in that discussion > >>> to that thread: > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >> July/023934.html > >>> which I now turned into a RFR. > >> > >> Thanks. > >> > >> I think I see what happened to the email thread for me; it looks like one of > >> Andrew?s replies went to hotspot-compiler-dev but not hotspot-runtime- > >> dev, > >> and I was not subscribed to the compiler list this morning. > >> > >> I like the idea, just quibbling over details. I've only reviewed > >> macros.hpp so far; the rest looks like it can wait until the details > >> are settled. > >> > >> ------------------------------------------------------------------------------ > >> src/share/vm/utilities/macros.hpp > >> 470 // Helper macros to workaround existing #defines that spoil > >> 471 // the macro expansion. Detected so far: linux=1, sparc=1. > >> > >> This issue can be dodged by making the leading underscore part of the > >> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, use > >> instead > >> > >> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ > >> > >> Note the insertion of leading "_" for the values. > >> > >> Then the whole macro block can be written as > >> > >> #define cpu_header_stem(basename) PASTE_TOKENS(basename, > >> INCLUDE_SUFFIX_CPU) > >> #define os_header_stem(basename) PASTE_TOKENS(basename, > >> INCLUDE_SUFFIX_OS) > >> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, > >> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > >> > >> #define cpu_header(basename) > XSTR(cpu_header_stem(basename).hpp) > >> #define cpu_header_inline(basename) > >> XSTR(cpu_header_stem(basename).inline.hpp) > >> #define os_header(basename) XSTR(os_header_stem(basename).hpp) > >> #define os_header_inline(basename) > >> XSTR(os_header_stem(basename).inline.hpp) > >> #define os_cpu_header(basename) > >> XSTR(os_cpu_header_stem(basename).hpp) > >> #define os_cpu_header_inline(basename) > >> XSTR(os_cpu_header_stem(basename).inline.hpp) > >> > >> And SUB is no longer used... > >> > >> If some future build system wants brackets instead of strings, just > >> replace XSTR(...) with <...>. > >> > >> We lose if _linux or _sparc (for example) are defined, but that's true > >> for the webrev.01 code too. But note that underscore followed by a > >> lowercase letter is not in the reserved word pattern for C/C++. > >> > >> BTW, my preference would be to use uppercase for the macro names. I > >> don't know what others think about that. > >> > >> ------------------------------------------------------------------------------ > > From david.holmes at oracle.com Fri Jul 15 13:16:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 23:16:55 +1000 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5788C086.6050509@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> Message-ID: On 15/07/2016 8:52 PM, Alan Burlison wrote: > On 15/07/2016 07:28, David Holmes wrote: > >> Okay I looked further into the affect of this (I recalled we also use it >> in a test to deal with a sigwait API issue) and see that it changes the >> form of the function prototypes (and underlying implementation) so it >> won't silently change anything. > > Yes, that's another one of the places it is used and for that and other > places it changes the APIs provided from the draft ones to the > standards-conforming ones. This is all the result of decision made back > in Solaris 2.4 that we are still living with, although it will be > addressed in future releases. > >> Looking further into this aspect I can't help but feel we should be >> defining: >> >> _POSIX_C_SOURCE=200112L >> >> which would also fix the current problem and more generally make it >> clear we are intending to use specific standard-based API's. But that is >> going somewhat further than the scope of the current fix - and may run >> into unexpected consequences (we've been somewhat lax at programming to >> specific language and API versions). > > Actually you almost certainly don't want that. Asking for a specific > POSIX version means exactly that, you'll get the APIs defined in that > version and nothing else. If you are using non-POSIX APIs, they will > disappear, because what you are asking for is an environment which all > conforming POSIX implementations will provide, i.e. lowest common > denominator. The implementation in the header files doesn't always match > up with that 100%, but that's theoretically how it should work. Well, I think we do ask for _XOPEN API's in places, but yes the mix of POSIX, XOPEN, SUSv3(?), other? is a somewhat tangled mess. > My general advice would be to set the smallest possible number of most > restricted-scope feature macros that you can to get the behaviour you > want, which in this case is _POSIX_PTHREAD_SEMANTICS. Ok. Thanks, David From Alan.Burlison at oracle.com Fri Jul 15 13:23:14 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 15 Jul 2016 14:23:14 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> Message-ID: <5788E3C2.7070508@oracle.com> On 15/07/2016 14:16, David Holmes wrote: > Well, I think we do ask for _XOPEN API's in places, but yes the mix of > POSIX, XOPEN, SUSv3(?), other? is a somewhat tangled mess. Yes, agreed. It's a mess we are aiming to sort out but it isn't done yet. -- Alan Burlison -- From Alan.Burlison at oracle.com Fri Jul 15 13:40:09 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 15 Jul 2016 14:40:09 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <5787BEE7.4000501@oracle.com> Message-ID: <5788E7B9.1030607@oracle.com> On 14/07/2016 17:44, Daniel D. Daugherty wrote: > I'll leave it up to you and David H. to work out. > > Full disclosure: the sooner this review gets wrapped up, the > sooner I can push the bits since I'm the sponsor. :-) From David H: > So I'm okay with the fix as it stands. So I think we are good to go? -- Alan Burlison -- From frederic.parain at oracle.com Fri Jul 15 14:14:01 2016 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 15 Jul 2016 10:14:01 -0400 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED In-Reply-To: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> References: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> Message-ID: David, Fix looks good to me, thank you for cleaning this up. Fred On 14/07/2016 00:26, David Holmes wrote: > The bug report for this is confidential but quite simply all of the > little tweaks and knobs we added to the open build and source files to > support the Java SE Embedded product no longer need to be there for JDK > 9. A lot of this has already been addressed in relation to other changes > (eg. new hotspot build), but this cleans out the rest. > > webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ > > There are related JDK changes being handled in a separate review thread. > If you like you can see them all: > > http://cr.openjdk.java.net/~dholmes/8140723/ > > Thanks, > David -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From daniel.daugherty at oracle.com Fri Jul 15 14:51:16 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jul 2016 08:51:16 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5788E7B9.1030607@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <5787BEE7.4000501@oracle.com> <5788E7B9.1030607@oracle.com> Message-ID: On 7/15/16 7:40 AM, Alan Burlison wrote: > On 14/07/2016 17:44, Daniel D. Daugherty wrote: > >> I'll leave it up to you and David H. to work out. >> >> Full disclosure: the sooner this review gets wrapped up, the >> sooner I can push the bits since I'm the sponsor. :-) > > From David H: > >> So I'm okay with the fix as it stands. > > So I think we are good to go? I'm good to go with this. Just to be sure: We're going with the last version that went out for review, i.e., no changes since the last review. Please confirm. Dan From Alan.Burlison at oracle.com Fri Jul 15 15:08:20 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 15 Jul 2016 16:08:20 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <5787BEE7.4000501@oracle.com> <5788E7B9.1030607@oracle.com> Message-ID: <5788FC64.5050804@oracle.com> On 15/07/2016 15:51, Daniel D. Daugherty wrote: > I'm good to go with this. Just to be sure: We're going with the > last version that went out for review, i.e., no changes since > the last review. Please confirm. AFAIK, yes. -- Alan Burlison -- From daniel.daugherty at oracle.com Fri Jul 15 16:37:10 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jul 2016 10:37:10 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5788E3C2.7070508@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> Message-ID: On 7/15/16 7:23 AM, Alan Burlison wrote: > On 15/07/2016 14:16, David Holmes wrote: > >> Well, I think we do ask for _XOPEN API's in places, but yes the mix of >> POSIX, XOPEN, SUSv3(?), other? is a somewhat tangled mess. > > Yes, agreed. It's a mess we are aiming to sort out but it isn't done yet. > Here's the commit comment: $ cat commit.txt 8160997: Solaris: deprecated and interfaces should be replaced Summary: Use final POSIX 1003.1c versions of getgrgid_r(), getgrnam_r(), getpwnam_r(), and getpwuid_r(). Reviewed-by: alanb, dcubed, simonis, dholmes Contributed-by: alan.burlison at oracle.com I'll be committing the changeset shortly and submitting to JPRT-west. Dan From Alan.Burlison at oracle.com Fri Jul 15 16:48:04 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 15 Jul 2016 17:48:04 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> Message-ID: <578913C4.8060901@oracle.com> On 15/07/2016 17:37, Daniel D. Daugherty wrote: > Here's the commit comment: > > $ cat commit.txt > 8160997: Solaris: deprecated and interfaces should be > replaced > Summary: Use final POSIX 1003.1c versions of getgrgid_r(), getgrnam_r(), > getpwnam_r(), and getpwuid_r(). > Reviewed-by: alanb, dcubed, simonis, dholmes > Contributed-by: alan.burlison at oracle.com > > I'll be committing the changeset shortly and submitting to JPRT-west. Excellent, thanks. Once it's done I can apply for author status and stop bugging you all to host webrevs :-) -- Alan Burlison -- From daniel.daugherty at oracle.com Fri Jul 15 16:50:50 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jul 2016 10:50:50 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <578913C4.8060901@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> <578913C4.8060901@oracle.com> Message-ID: <4395aec9-4719-c224-8afb-ab010425c872@oracle.com> On 7/15/16 10:48 AM, Alan Burlison wrote: > On 15/07/2016 17:37, Daniel D. Daugherty wrote: > >> Here's the commit comment: >> >> $ cat commit.txt >> 8160997: Solaris: deprecated and interfaces should be >> replaced >> Summary: Use final POSIX 1003.1c versions of getgrgid_r(), getgrnam_r(), >> getpwnam_r(), and getpwuid_r(). >> Reviewed-by: alanb, dcubed, simonis, dholmes >> Contributed-by: alan.burlison at oracle.com >> >> I'll be committing the changeset shortly and submitting to JPRT-west. > > Excellent, thanks. Once it's done I can apply for author status and > stop bugging you all to host webrevs :-) Ummmm... Is this your first commit? Or did I miss an earlier one? Dan From Alan.Burlison at oracle.com Fri Jul 15 17:21:20 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 15 Jul 2016 18:21:20 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <4395aec9-4719-c224-8afb-ab010425c872@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> <578913C4.8060901@oracle.com> <4395aec9-4719-c224-8afb-ab010425c872@oracle.com> Message-ID: <57891B90.4080309@oracle.com> On 15/07/2016 17:50, Daniel D. Daugherty wrote: > Ummmm... Is this your first commit? Or did I miss an earlier one? It will be the second. JDK-8160350 was the first. -- Alan Burlison -- From daniel.daugherty at oracle.com Fri Jul 15 18:12:38 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jul 2016 12:12:38 -0600 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <57891B90.4080309@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> <578913C4.8060901@oracle.com> <4395aec9-4719-c224-8afb-ab010425c872@oracle.com> <57891B90.4080309@oracle.com> Message-ID: <854768ee-258e-0812-7029-1ab4204a8ffe@oracle.com> On 7/15/16 11:21 AM, Alan Burlison wrote: > On 15/07/2016 17:50, Daniel D. Daugherty wrote: > >> Ummmm... Is this your first commit? Or did I miss an earlier one? > > It will be the second. JDK-8160350 was the first. > Yes... thanks for the reminder... I even reviewed that one... :-) Dan From kim.barrett at oracle.com Fri Jul 15 18:18:48 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Jul 2016 14:18:48 -0400 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: <213C9066-3567-48E9-B38E-5CD97C08063A@oracle.com> > On Jul 15, 2016, at 8:17 AM, Lindenmaier, Goetz wrote: > > Hi, > > I made a new webrev: > - '_' is added in makefile > - uses Kim's macros > - macros are capitalized > - more comments in macros.hpp > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ Updated macrology looks good. I won?t be able to review the rest any time soon, so don?t wait for me. From serguei.spitsyn at oracle.com Fri Jul 15 20:48:43 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Jul 2016 13:48:43 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> Message-ID: <57894C2B.8050308@oracle.com> Hi Jiangli, It looks good in general. Some minor comments. /src/share/vm/memory/metaspaceShared.cpp 1239 void MetaspaceShared::check_sharing_for_post_class_file_load_hook() { 1240 if (JvmtiExport::should_post_class_file_load_hook() && UseSharedSpaces) { 1241 // If RequireSharedSpaces is true, report error and exit. 1242 if (RequireSharedSpaces) { 1243 tty->print_cr("An error has occurred while loading shared class."); 1244 tty->print_cr("Tool agent requires sharing to be disabled."); 1245 vm_exit(1); 1246 } It seems, the printed log at L1243-1244 is out of context. There is no loading of a shared class as this function is called during the initialization. src/share/vm/memory/metaspaceShared.hpp + //Check sharing and JvmtiExport::should_post_class_file_load_hook requirement. Please, add a space after the "//". There is still a question about what to do with this code in the jvmtiManageCapabilities.cpp: // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } Should we make it unconditional and independent from the UseSharedSpaces flag? Thanks, Serguei On 7/13/16 17:06, Jiangli Zhou wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ > > Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). > Agent specified via command line: > With -Xshare:on, report error and exit. > Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. > With -Xshare:auto, disallow loading shared class > If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). > If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). > Agent is attached: > With -Xshare:on and -Xshare:auto > Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. > Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the > 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. > > Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. > > Thanks, > Jiangli > > > >> On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: >> >> Hi Ioi, >> >>> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >>> >>> Hi Jiangli, >>> >>> I agree what what Karen has said. >>> >>> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >>> >>> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. >> Agreed. >> >>> Also, maybe this check can also be removed? >>> >>> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >>> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >>> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >>> >>> Since the same check is already done in the "inner" load_shared_class() method. >> I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. >> >> Thanks, >> Jiangli >> >>> Thanks >>> - Ioi >>> >>> >>> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>>> Hi Karen, >>>> >>>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>>> >>>>> Jiangli, >>>>> >>>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>>> >>>>> I agree with not quitting the vm on agent attach. >>>>> I actually think we also want the agent attach to succeed - see below. >>>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>>> >>>>>> (Adding serviceability-dev at openjdk.java.net) >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> I think the two blocks of >>>>>> >>>>>> if (RequireSharedSpaces) { >>>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>>> vm_exit(1); >>>>>> } >>>>>> >>>>>> should be removed. >>>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>>> but no forcing of using the shared spaces if there is an agent. >>>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>>> Totally agree - we should not quit the VM. >>>>> >>>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>>> >>>>>> jvmtiError >>>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>>> >>>>>> ... >>>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>>> + } >>>>>> record_class_file_load_hook_enabled(); >>>>>> } >>>>>> ? >>>>>> } >>>>>> >>>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>>> Thanks >>>>>> - Ioi >>>>> Jiangli: >>>>> >>>>> Minor code review comments: >>>>> >>>>> metaspace.cpp line 3181: CFHL-> CFLH >>>>> >>>>> metaspace.cpp: >>>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>>> >>>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>>> bug: JDK-8141341 >>>>>>> >>>>>>> With -Xshare:on >>>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>>> >>>>>>> With -Xshare:auto >>>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>>> >>>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>> From jiangli.zhou at oracle.com Fri Jul 15 21:51:38 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 15 Jul 2016 14:51:38 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <57894C2B.8050308@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> <57894C2B.8050308@oracle.com> Message-ID: <2BC2F0E3-C753-4F3B-BAA8-B802179DA1CA@oracle.com> Hi Serguei, Thank you for the comments. > On Jul 15, 2016, at 1:48 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jiangli, > > It looks good in general. > > Some minor comments. > /src/share/vm/memory/metaspaceShared.cpp > > 1239 void MetaspaceShared::check_sharing_for_post_class_file_load_hook() { > 1240 if (JvmtiExport::should_post_class_file_load_hook() && UseSharedSpaces) { > 1241 // If RequireSharedSpaces is true, report error and exit. > 1242 if (RequireSharedSpaces) { > 1243 tty->print_cr("An error has occurred while loading shared class."); > 1244 tty->print_cr("Tool agent requires sharing to be disabled."); > 1245 vm_exit(1); > 1246 } > It seems, the printed log at L1243-1244 is out of context. There is no loading of a shared class as this function is called during the initialization. src/share/vm/memory/metaspaceShared.hpp Agreed. The message is out of context. Ioi suggested to remove the above check. That would results different behaviors for agents started from command-line running with -Xshare:on. In some cases the VM terminates, in other cases it continues but not loading from shared archive. Since the goal for this bug fix is backwards compatibility with 8 and it is a temporary solution, I agree with Ioi and will remove above function. > + //Check sharing and JvmtiExport::should_post_class_file_load_hook requirement. > Please, add a space after the "//". There is still a question about what to do with this code in the jvmtiManageCapabilities.cpp: Same as above. Will remove the comment. > // if the capability sets are initialized in the onload phase then > // it happens before class data sharing (CDS) is initialized. If it > // turns out that CDS gets disabled then we must adjust the always > // capabilities. To ensure a consistent view of the capabililties > // anything we add here should already be in the onload set. > void JvmtiManageCapabilities::recompute_always_capabilities() { > if (!UseSharedSpaces) { > jvmtiCapabilities jc = always_capabilities; > jc.can_generate_all_class_hook_events = 1; > always_capabilities = jc; > } > } > Should we make it unconditional and independent from the UseSharedSpaces flag? I agree, the UseSharedSpaces check does not seem to be needed here. Looking at related code, looks like can_generate_all_class_hook_events is set to 1 by JvmtiManageCapabilities::init_onload_capabilities(). So it is always enabled already. I wonder what the special handling of can_generate_all_class_hook_events is needed here then. Do you have any insight? I?ll file a separate bug for removing the UseSharedSpaces check from recompute_always_capabilities(). Thanks, Jiangli > Thanks, Serguei On 7/13/16 17:06, Jiangli Zhou wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ >> >> Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). >> Agent specified via command line: >> With -Xshare:on, report error and exit. >> Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. >> With -Xshare:auto, disallow loading shared class >> If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). >> If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). >> Agent is attached: >> With -Xshare:on and -Xshare:auto >> Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. >> Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the >> 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. >> >> Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. >> >> Thanks, >> Jiangli >> >> >> >>> On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: >>> >>> Hi Ioi, >>> >>>> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >>>> >>>> Hi Jiangli, >>>> >>>> I agree what what Karen has said. >>>> >>>> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >>>> >>>> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. >>> Agreed. >>> >>>> Also, maybe this check can also be removed? >>>> >>>> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >>>> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >>>> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >>>> >>>> Since the same check is already done in the "inner" load_shared_class() method. >>> I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. >>> >>> Thanks, >>> Jiangli >>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>>>> Hi Karen, >>>>> >>>>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>>>> >>>>>> Jiangli, >>>>>> >>>>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>>>> >>>>>> I agree with not quitting the vm on agent attach. >>>>>> I actually think we also want the agent attach to succeed - see below. >>>>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>>>> >>>>>>> (Adding serviceability-dev at openjdk.java.net ) >>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> I think the two blocks of >>>>>>> >>>>>>> if (RequireSharedSpaces) { >>>>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>>>> vm_exit(1); >>>>>>> } >>>>>>> >>>>>>> should be removed. >>>>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>>>> but no forcing of using the shared spaces if there is an agent. >>>>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>>>> Totally agree - we should not quit the VM. >>>>>> >>>>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>>>> >>>>>>> jvmtiError >>>>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>>>> >>>>>>> ... >>>>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>>>> + } >>>>>>> record_class_file_load_hook_enabled(); >>>>>>> } >>>>>>> ? >>>>>>> } >>>>>>> >>>>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>>>> Thanks >>>>>>> - Ioi >>>>>> Jiangli: >>>>>> >>>>>> Minor code review comments: >>>>>> >>>>>> metaspace.cpp line 3181: CFHL-> CFLH >>>>>> >>>>>> metaspace.cpp: >>>>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>>> >>>>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>>>> bug: JDK-8141341 >>>>>>>> >>>>>>>> With -Xshare:on >>>>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>>>> >>>>>>>> With -Xshare:auto >>>>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>>>> >>>>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jiangli >>>>>>>> >>>>>>>> From david.holmes at oracle.com Fri Jul 15 22:04:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Jul 2016 08:04:11 +1000 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <5788E3C2.7070508@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> Message-ID: <0fede411-2f22-7409-052f-3c4d202254ae@oracle.com> On 15/07/2016 11:23 PM, Alan Burlison wrote: > On 15/07/2016 14:16, David Holmes wrote: > >> Well, I think we do ask for _XOPEN API's in places, but yes the mix of >> POSIX, XOPEN, SUSv3(?), other? is a somewhat tangled mess. > > Yes, agreed. It's a mess we are aiming to sort out but it isn't done yet. To be clear I was talking about the mess in the hotspot code :) Cheers, David From david.holmes at oracle.com Fri Jul 15 22:04:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Jul 2016 08:04:33 +1000 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED In-Reply-To: References: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> Message-ID: <85a05426-7b33-c8ba-56ec-4caa70d9f0f9@oracle.com> Thanks Fred! David On 16/07/2016 12:14 AM, frederic parain wrote: > David, > > Fix looks good to me, thank you for > cleaning this up. > > Fred > > On 14/07/2016 00:26, David Holmes wrote: >> The bug report for this is confidential but quite simply all of the >> little tweaks and knobs we added to the open build and source files to >> support the Java SE Embedded product no longer need to be there for JDK >> 9. A lot of this has already been addressed in relation to other changes >> (eg. new hotspot build), but this cleans out the rest. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ >> >> There are related JDK changes being handled in a separate review thread. >> If you like you can see them all: >> >> http://cr.openjdk.java.net/~dholmes/8140723/ >> >> Thanks, >> David > From serguei.spitsyn at oracle.com Fri Jul 15 23:46:16 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Jul 2016 16:46:16 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <2BC2F0E3-C753-4F3B-BAA8-B802179DA1CA@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> <57894C2B.8050308@oracle.com> <2BC2F0E3-C753-4F3B-BAA8-B802179DA1CA@oracle.com> Message-ID: <578975C8.8000807@oracle.com> On 7/15/16 14:51, Jiangli Zhou wrote: > Hi Serguei, > > Thank you for the comments. > >> On Jul 15, 2016, at 1:48 PM, serguei.spitsyn at oracle.com >> wrote: >> >> Hi Jiangli, >> >> It looks good in general. >> >> Some minor comments. >> /src/share/vm/memory/metaspaceShared.cpp 1239 void >> MetaspaceShared::check_sharing_for_post_class_file_load_hook() { >> 1240 if (JvmtiExport::should_post_class_file_load_hook() && >> UseSharedSpaces) { >> 1241 // If RequireSharedSpaces is true, report error and exit. >> 1242 if (RequireSharedSpaces) { >> 1243 tty->print_cr("An error has occurred while loading shared class."); >> 1244 tty->print_cr("Tool agent requires sharing to be disabled."); >> 1245 vm_exit(1); >> 1246 } >> It seems, the printed log at L1243-1244 is out of context. There >> is no loading of a shared class as this function is called during the >> initialization. src/share/vm/memory/metaspaceShared.hpp > Agreed. The message is out of context. > Ioi suggested to remove the above check. That would results different > behaviors for agents started from command-line running with > -Xshare:on. In some cases the VM terminates, in other cases it > continues but not loading from shared archive. Since the goal for this > bug fix is backwards compatibility with 8 and it is a temporary > solution, I agree with Ioi and will remove above function. I had similar thoughts and agree with this approach. >> + //Check sharing and JvmtiExport::should_post_class_file_load_hook >> requirement. >> Please, add a space after the "//". There is still a question about >> what to do with this code in the jvmtiManageCapabilities.cpp: > Same as above. Will remove the comment. Ok. >> // if the capability sets are initialized in the onload phase then // >> it happens before class data sharing (CDS) is initialized. If it // >> turns out that CDS gets disabled then we must adjust the always // >> capabilities. To ensure a consistent view of the capabililties // >> anything we add here should already be in the onload set. void >> JvmtiManageCapabilities::recompute_always_capabilities() { if >> (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; >> jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } >> Should we make it unconditional and independent from the >> UseSharedSpaces flag? > I agree, the UseSharedSpaces check does not seem to be needed here. Good. > Looking at related code, looks like can_generate_all_class_hook_events > is set to 1 by JvmtiManageCapabilities::init_onload_capabilities(). So > it is always enabled already. The onload_capabilities and always capabilities are different. But I'm not sure why they need to be differentiated. In fact, this code is tricky and hard to understand. > I wonder what the special handling of > can_generate_all_class_hook_events is needed here then. Do you have > any insight? Honestly, I'm not sure yet. An accurate analysis is needed to get to a conclusion. > I?ll file a separate bug for removing the UseSharedSpaces check from > recompute_always_capabilities(). Ok, thanks. Thanks, Serguei > Thanks, > Jiangli >> Thanks, Serguei On 7/13/16 17:06, Jiangli Zhou wrote: >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ >>> >>> Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). >>> Agent specified via command line: >>> With -Xshare:on, report error and exit. >>> Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. >>> With -Xshare:auto, disallow loading shared class >>> If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). >>> If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). >>> Agent is attached: >>> With -Xshare:on and -Xshare:auto >>> Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. >>> Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the >>> 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. >>> >>> Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. >>> >>> Thanks, >>> Jiangli >>> >>> >>> >>>> On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: >>>> >>>> Hi Ioi, >>>> >>>>> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> I agree what what Karen has said. >>>>> >>>>> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >>>>> >>>>> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. >>>> Agreed. >>>> >>>>> Also, maybe this check can also be removed? >>>>> >>>>> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >>>>> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >>>>> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >>>>> >>>>> Since the same check is already done in the "inner" load_shared_class() method. >>>> I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> >>>>> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>>>>> Hi Karen, >>>>>> >>>>>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>>>>> >>>>>>> Jiangli, >>>>>>> >>>>>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>>>>> >>>>>>> I agree with not quitting the vm on agent attach. >>>>>>> I actually think we also want the agent attach to succeed - see below. >>>>>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>> (Addingserviceability-dev at openjdk.java.net) >>>>>>>> >>>>>>>> Hi Jiangli, >>>>>>>> >>>>>>>> I think the two blocks of >>>>>>>> >>>>>>>> if (RequireSharedSpaces) { >>>>>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>>>>> vm_exit(1); >>>>>>>> } >>>>>>>> >>>>>>>> should be removed. >>>>>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>>>>> but no forcing of using the shared spaces if there is an agent. >>>>>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>>>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>>>>> Totally agree - we should not quit the VM. >>>>>>> >>>>>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>>>>> >>>>>>>> jvmtiError >>>>>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>>>>> >>>>>>>> ... >>>>>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>>>>> + } >>>>>>>> record_class_file_load_hook_enabled(); >>>>>>>> } >>>>>>>> ? >>>>>>>> } >>>>>>>> >>>>>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>>>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>>>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>>>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>> Jiangli: >>>>>>> >>>>>>> Minor code review comments: >>>>>>> >>>>>>> metaspace.cpp line 3181: CFHL-> CFLH >>>>>>> >>>>>>> metaspace.cpp: >>>>>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>>>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>>>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>>>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>>>>> >>>>>>> thanks, >>>>>>> Karen >>>>>>> >>>>>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>>>>> >>>>>>>>> webrev:http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>>>>> bug: JDK-8141341 >>>>>>>>> >>>>>>>>> With -Xshare:on >>>>>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>>>>> >>>>>>>>> With -Xshare:auto >>>>>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>>>>> >>>>>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jiangli >>>>>>>>> >>>>>>>>> From harold.seigel at oracle.com Sun Jul 17 23:05:52 2016 From: harold.seigel at oracle.com (harold seigel) Date: Sun, 17 Jul 2016 19:05:52 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers Message-ID: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Hi, Please review these Hotspot VM only changes to process the seven module-specific options that have been renamed to have gnu-like names. JDK changes for this bug will be reviewed separately. Descriptions of these options are here . For these six options, --module-path, --upgrade-module-path, --add-modules, --limit-modules, --add-reads, and --add-exports, the JVM just sets a system property. For the --patch-module option, the JVM sets a system property and then processes the option in the same way as when it was named -Xpatch. Additionally, the JVM now checks properties specified on the command line. If a property matches one of the properties used by one of the above options then the JVM ignores the property. This forces users to use the explicit option when wanting to do things like add a module or a package export. The RFR contains two new tests. Also, many existing tests were changed to use the new option names. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ The changes were tested with the JCK lang and VM tests, the JTreg hotspot tests, and the RBT hotspot nightlies. Thanks, Harold From david.holmes at oracle.com Mon Jul 18 06:03:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 16:03:28 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: Hi Goetz, Again thanks for tackling this! On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > Hi, > > I made a new webrev: > - '_' is added in makefile > - uses Kim's macros > - macros are capitalized > - more comments in macros.hpp > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ Generally looks okay, a couple of clarifications and comments below. make/gensrc/GensrcAdlc.gmk So the change from HOTSPOT_TARGET_CPU to HOTSPOT_TARGET_CPU_ARCH only affects the generated files right? For our closed ports we still have the _32/_64 source files in a common arch directory, but I don't think that needs to be reflected in the generated files. (Sorry I haven't had the time yet to apply this patch and see what needs to be changed on the closed side - but will start that once I send this :).) make/lib/CompileJvm.gmk Hmm but this change assumes no more _32/_64 header files if I read it right ?? So I'll need a common file that dispatches internally for 32-bit and 64-bit. --- src/os/posix/vm/os_posix.cpp I'm wondering if we can use a similar trick to avoid this kind of switch(OS) statement: #ifdef TARGET_OS_FAMILY_linux Linux::ucontext_set_pc(ctx, pc); #elif defined(TARGET_OS_FAMILY_solaris) Solaris::ucontext_set_pc(ctx, pc); ... ie something like: SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); ? :) --- src/share/vm/code/nmethod.cpp Not clear why the platform include can simply be elided here ?? --- src/share/vm/jvmci/jvmciRuntime.cpp Shouldn't: ! #endif // !LP64 be: ! #endif // LP64 --- src/share/vm/prims/jni_md.h src/share/vm/prims/jvm.h // Can not use CPU_HEADER() macro, as it appends .hpp can we not define a second form, eg CPU_HEADER_H, that appends.h instead? --- src/share/vm/runtime/os.hpp Should we convert setjmp.h include to: #ifndef _WINDOWS #include #endif #ifdef __APPLE__ ... #endif ? BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the compiler itself? --- src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp Don't understand the point of this: 28 #if defined(VM_LITTLE_ENDIAN) 29 // Aix is not littel endian. 30 #endif // VM_LITTLE_ENDIAN also typo: littel Thanks, David ----- > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 15. Juli 2016 11:11 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>> HI Kim, >>> >>> thanks for this version of the macros, it's working on all the platforms >>> I can build. >>> >>> Actually, I would prefer having the '_' in the macros and not on the >>> command line. This way, parts of the name construction are in >>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>> the search path is also in the makefile, and uses the very same string >>> as the file suffixes. (Without '_', one could include that in the macro, too.) >>> >>> But overall, I consider this a detail and am as fine with your solution >>> as with the SUB() macros. What is better is that the linux=1 etc >>> problems are avoided. >>> >>> Any more opinions whether the macros should be upper case? >> >> Yeah they probably should be. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>> To: Lindenmaier, Goetz >>>> Cc: Andrew Haley ; hotspot-compiler- >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>> wrote: >>>>> >>>>> Hi everybody, >>>>> >>>>> please take into account that these macros are only used within 20 lines >> of >>>>> the file macro.hpp. The code everybody needs to understand is >>>>> #include cpu_header(bytes) >>>>> which, in this example, is in file bytes.hpp and expands to >>>> bytes_.hpp. >>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>> >>>>> I really would appreciate if I don't have to spend days editing the >>>>> 12 lines that use SUB(). >>>>> >>>>> @Kim >>>>> I'm working on the s390 port, and posted my current progress claiming >>>>> that the biggest shared change I need to do is adding the #includes. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>> July/023782.html >>>>> This arose the discussion about the includes. >>>>> Later I posted a prototype of what Volker proposed in that discussion >>>>> to that thread: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>> July/023934.html >>>>> which I now turned into a RFR. >>>> >>>> Thanks. >>>> >>>> I think I see what happened to the email thread for me; it looks like one of >>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot-runtime- >>>> dev, >>>> and I was not subscribed to the compiler list this morning. >>>> >>>> I like the idea, just quibbling over details. I've only reviewed >>>> macros.hpp so far; the rest looks like it can wait until the details >>>> are settled. >>>> >>>> ------------------------------------------------------------------------------ >>>> src/share/vm/utilities/macros.hpp >>>> 470 // Helper macros to workaround existing #defines that spoil >>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>> >>>> This issue can be dodged by making the leading underscore part of the >>>> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, use >>>> instead >>>> >>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ >>>> >>>> Note the insertion of leading "_" for the values. >>>> >>>> Then the whole macro block can be written as >>>> >>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >>>> INCLUDE_SUFFIX_CPU) >>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>> INCLUDE_SUFFIX_OS) >>>> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, >>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>> >>>> #define cpu_header(basename) >> XSTR(cpu_header_stem(basename).hpp) >>>> #define cpu_header_inline(basename) >>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>> #define os_header(basename) XSTR(os_header_stem(basename).hpp) >>>> #define os_header_inline(basename) >>>> XSTR(os_header_stem(basename).inline.hpp) >>>> #define os_cpu_header(basename) >>>> XSTR(os_cpu_header_stem(basename).hpp) >>>> #define os_cpu_header_inline(basename) >>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>> >>>> And SUB is no longer used... >>>> >>>> If some future build system wants brackets instead of strings, just >>>> replace XSTR(...) with <...>. >>>> >>>> We lose if _linux or _sparc (for example) are defined, but that's true >>>> for the webrev.01 code too. But note that underscore followed by a >>>> lowercase letter is not in the reserved word pattern for C/C++. >>>> >>>> BTW, my preference would be to use uppercase for the macro names. I >>>> don't know what others think about that. >>>> >>>> ------------------------------------------------------------------------------ >>> From Alan.Bateman at oracle.com Mon Jul 18 06:59:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Jul 2016 07:59:20 +0100 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: <2fefa677-3af1-bed8-be2c-604781ab0600@oracle.com> On 18/07/2016 00:05, harold seigel wrote: > Hi, > > Please review these Hotspot VM only changes to process the seven > module-specific options that have been renamed to have gnu-like > names. JDK changes for this bug will be reviewed separately. > > Descriptions of these options are here > . For these six options, > --module-path, --upgrade-module-path, --add-modules, --limit-modules, > --add-reads, and --add-exports, the JVM just sets a system property. > For the --patch-module option, the JVM sets a system property and then > processes the option in the same way as when it was named -Xpatch. > > Additionally, the JVM now checks properties specified on the command > line. If a property matches one of the properties used by one of the > above options then the JVM ignores the property. This forces users to > use the explicit option when wanting to do things like add a module or > a package export. > > The RFR contains two new tests. Also, many existing tests were > changed to use the new option names. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ I assume the module-info.java for jdk.hotspot.agent should be ignored. Also, just to say that we'll probably aim to bring all the CLI changes into jdk9/dev in a few weeks, maybe the week of Aug 15-19. This requires coordinated changes in all repos. This initial push will have both the old and new module options, then we'll remove the old module options after a transition period. Not important for reviewing the hotspot changes, but might be useful in case there are questions. -Alan From Alan.Bateman at oracle.com Mon Jul 18 07:13:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Jul 2016 08:13:48 +0100 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: On 18/07/2016 00:05, harold seigel wrote: > Hi, > > Please review these Hotspot VM only changes to process the seven > module-specific options that have been renamed to have gnu-like > names. JDK changes for this bug will be reviewed separately. > > Descriptions of these options are here > . For these six options, > --module-path, --upgrade-module-path, --add-modules, --limit-modules, > --add-reads, and --add-exports, the JVM just sets a system property. > For the --patch-module option, the JVM sets a system property and then > processes the option in the same way as when it was named -Xpatch. > > Additionally, the JVM now checks properties specified on the command > line. If a property matches one of the properties used by one of the > above options then the JVM ignores the property. This forces users to > use the explicit option when wanting to do things like add a module or > a package export. > > The RFR contains two new tests. Also, many existing tests were > changed to use the new option names. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ A passing comment on unsupported_options (options not allowed when using -Xshare:dump) then it has -m in the list. I assume that should not be there. That is java launcher option, the VM don't see or unrecognize it, also it's long form is --module. -Alan From goetz.lindenmaier at sap.com Mon Jul 18 07:15:09 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Jul 2016 07:15:09 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> Hi David, thanks for looking at all these files in more detail! > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 18. Juli 2016 08:03 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Hi Goetz, > > Again thanks for tackling this! > > On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I made a new webrev: > > - '_' is added in makefile > > - uses Kim's macros > > - macros are capitalized > > - more comments in macros.hpp > > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ > > Generally looks okay, a couple of clarifications and comments below. > > > make/gensrc/GensrcAdlc.gmk > > So the change from HOTSPOT_TARGET_CPU to > HOTSPOT_TARGET_CPU_ARCH only > affects the generated files right? Yes. > For our closed ports we still have > the _32/_64 source files in a common arch directory, but I don't think > that needs to be reflected in the generated files. (Sorry I haven't had > the time yet to apply this patch and see what needs to be changed on the > closed side - but will start that once I send this :).) If I run plain configure, it generates a directory that has the word size in it's name: linux-x86_64-normal-server-release If I configure --with-target-bits=32, it builds to linux-x86-normal-server-release, so I figured this should be fine. > make/lib/CompileJvm.gmk > > Hmm but this change assumes no more _32/_64 header files if I read it > right ?? So I'll need a common file that dispatches internally for > 32-bit and 64-bit. Yes. There is a single file in cpu/x86 where this did not hold: stubRoutines But this was rather small. And there anyways was a common file that was included in both. > src/os/posix/vm/os_posix.cpp > > I'm wondering if we can use a similar trick to avoid this kind of > switch(OS) statement: > > #ifdef TARGET_OS_FAMILY_linux > Linux::ucontext_set_pc(ctx, pc); > #elif defined(TARGET_OS_FAMILY_solaris) > Solaris::ucontext_set_pc(ctx, pc); > ... > > ie something like: > > SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > > ? :) Hmm, I had to add the '_' to the string in TARGET_SO... Actually I think the implementation should be moved to os_linux.cpp/os_bsd.cpp etc. > > --- > > src/share/vm/code/nmethod.cpp > > Not clear why the platform include can simply be elided here ?? It already includes code/nativeInst.hpp, which is the umbrella header for all the platform files. > src/share/vm/jvmci/jvmciRuntime.cpp > > Shouldn't: > > ! #endif // !LP64 > > be: > > ! #endif // LP64 Well, it ends the #else part ... but fixed anyways. > > --- > > src/share/vm/prims/jni_md.h > src/share/vm/prims/jvm.h > > // Can not use CPU_HEADER() macro, as it appends .hpp > > can we not define a second form, eg CPU_HEADER_H, that appends.h > instead? I'll need one for OS, one for CPU, and each will be used only once. So I figured not to do it. But probably I should do it to get is similar everywhere. > > --- > > src/share/vm/runtime/os.hpp > > Should we convert setjmp.h include to: > > #ifndef _WINDOWS > #include > #endif > #ifdef __APPLE__ > ... > #endif > ? Fixed. > > BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the > compiler itself? I wondered about that, too. Therefore I defined WINDOWS in the prototype webrev. Then I saw that our build is defining -D_WINDOWS *and* -DWIN32, and removed it again using _WINDOWS instead. Eventually both should be replaced by WINDOWS, but not in this change. > --- > > src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > > Don't understand the point of this: > > 28 #if defined(VM_LITTLE_ENDIAN) > 29 // Aix is not littel endian. > 30 #endif // VM_LITTLE_ENDIAN > > also typo: littel I just copied the linux_ppc code and removed the unused implementation. I wanted to document why there is this empty file. Best regards, Goetz. > Thanks, > David > ----- > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 15. Juli 2016 11:11 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>> HI Kim, > >>> > >>> thanks for this version of the macros, it's working on all the platforms > >>> I can build. > >>> > >>> Actually, I would prefer having the '_' in the macros and not on the > >>> command line. This way, parts of the name construction are in > >>> CompileJvm.gmk, other parts are in macros.hpp. But constructing > >>> the search path is also in the makefile, and uses the very same string > >>> as the file suffixes. (Without '_', one could include that in the macro, > too.) > >>> > >>> But overall, I consider this a detail and am as fine with your solution > >>> as with the SUB() macros. What is better is that the linux=1 etc > >>> problems are avoided. > >>> > >>> Any more opinions whether the macros should be upper case? > >> > >> Yeah they probably should be. > >> > >> Thanks, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>> To: Lindenmaier, Goetz > >>>> Cc: Andrew Haley ; hotspot-compiler- > >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>> wrote: > >>>>> > >>>>> Hi everybody, > >>>>> > >>>>> please take into account that these macros are only used within 20 > lines > >> of > >>>>> the file macro.hpp. The code everybody needs to understand is > >>>>> #include cpu_header(bytes) > >>>>> which, in this example, is in file bytes.hpp and expands to > >>>> bytes_.hpp. > >>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > >>>>> > >>>>> I really would appreciate if I don't have to spend days editing the > >>>>> 12 lines that use SUB(). > >>>>> > >>>>> @Kim > >>>>> I'm working on the s390 port, and posted my current progress claiming > >>>>> that the biggest shared change I need to do is adding the #includes. > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>> July/023782.html > >>>>> This arose the discussion about the includes. > >>>>> Later I posted a prototype of what Volker proposed in that discussion > >>>>> to that thread: > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>> July/023934.html > >>>>> which I now turned into a RFR. > >>>> > >>>> Thanks. > >>>> > >>>> I think I see what happened to the email thread for me; it looks like one > of > >>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- > runtime- > >>>> dev, > >>>> and I was not subscribed to the compiler list this morning. > >>>> > >>>> I like the idea, just quibbling over details. I've only reviewed > >>>> macros.hpp so far; the rest looks like it can wait until the details > >>>> are settled. > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> src/share/vm/utilities/macros.hpp > >>>> 470 // Helper macros to workaround existing #defines that spoil > >>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. > >>>> > >>>> This issue can be dodged by making the leading underscore part of the > >>>> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, > use > >>>> instead > >>>> > >>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ > >>>> > >>>> Note the insertion of leading "_" for the values. > >>>> > >>>> Then the whole macro block can be written as > >>>> > >>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, > >>>> INCLUDE_SUFFIX_CPU) > >>>> #define os_header_stem(basename) PASTE_TOKENS(basename, > >>>> INCLUDE_SUFFIX_OS) > >>>> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, > >>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > >>>> > >>>> #define cpu_header(basename) > >> XSTR(cpu_header_stem(basename).hpp) > >>>> #define cpu_header_inline(basename) > >>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>> #define os_header(basename) > XSTR(os_header_stem(basename).hpp) > >>>> #define os_header_inline(basename) > >>>> XSTR(os_header_stem(basename).inline.hpp) > >>>> #define os_cpu_header(basename) > >>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>> #define os_cpu_header_inline(basename) > >>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>> > >>>> And SUB is no longer used... > >>>> > >>>> If some future build system wants brackets instead of strings, just > >>>> replace XSTR(...) with <...>. > >>>> > >>>> We lose if _linux or _sparc (for example) are defined, but that's true > >>>> for the webrev.01 code too. But note that underscore followed by a > >>>> lowercase letter is not in the reserved word pattern for C/C++. > >>>> > >>>> BTW, my preference would be to use uppercase for the macro names. > I > >>>> don't know what others think about that. > >>>> > >>>> ------------------------------------------------------------------------------ > >>> From marcus.larsson at oracle.com Mon Jul 18 08:49:42 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 18 Jul 2016 10:49:42 +0200 Subject: RFR: 8061219: Implement unit-tests for UL Message-ID: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> Hi, Please review the following patch to add unit tests for the unified logging framework. Tests are written for the new gtest unit test framework. Most of the public functions for UL should be covered, but later additions have internal vm tests (in log.cpp) that will be ported separately. Webrev: http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8061219 Testing: New tests through JPRT Thanks, Marcus From david.holmes at oracle.com Mon Jul 18 09:06:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 19:06:00 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> Message-ID: <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for looking at all these files in more detail! > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 18. Juli 2016 08:03 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> Hi Goetz, >> >> Again thanks for tackling this! >> >> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I made a new webrev: >>> - '_' is added in makefile >>> - uses Kim's macros >>> - macros are capitalized >>> - more comments in macros.hpp >>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ >> >> Generally looks okay, a couple of clarifications and comments below. >> >> >> make/gensrc/GensrcAdlc.gmk >> >> So the change from HOTSPOT_TARGET_CPU to >> HOTSPOT_TARGET_CPU_ARCH only >> affects the generated files right? > Yes. >> For our closed ports we still have >> the _32/_64 source files in a common arch directory, but I don't think >> that needs to be reflected in the generated files. (Sorry I haven't had >> the time yet to apply this patch and see what needs to be changed on the >> closed side - but will start that once I send this :).) > If I run plain configure, it generates a directory that has the word size > in it's name: > linux-x86_64-normal-server-release > If I configure --with-target-bits=32, it builds to > linux-x86-normal-server-release, > so I figured this should be fine. Yes generated files are fine. >> make/lib/CompileJvm.gmk >> >> Hmm but this change assumes no more _32/_64 header files if I read it >> right ?? So I'll need a common file that dispatches internally for >> 32-bit and 64-bit. > Yes. > There is a single file in cpu/x86 where this did not hold: stubRoutines > But this was rather small. And there anyways was a common file > that was included in both. > >> src/os/posix/vm/os_posix.cpp >> >> I'm wondering if we can use a similar trick to avoid this kind of >> switch(OS) statement: >> >> #ifdef TARGET_OS_FAMILY_linux >> Linux::ucontext_set_pc(ctx, pc); >> #elif defined(TARGET_OS_FAMILY_solaris) >> Solaris::ucontext_set_pc(ctx, pc); >> ... >> >> ie something like: >> >> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >> >> ? :) > Hmm, I had to add the '_' to the string in TARGET_SO... > Actually I think the implementation should be moved to > os_linux.cpp/os_bsd.cpp etc. > >> >> --- >> >> src/share/vm/code/nmethod.cpp >> >> Not clear why the platform include can simply be elided here ?? > It already includes code/nativeInst.hpp, which is the umbrella header > for all the platform files. > >> src/share/vm/jvmci/jvmciRuntime.cpp >> >> Shouldn't: >> >> ! #endif // !LP64 >> >> be: >> >> ! #endif // LP64 > Well, it ends the #else part ... but fixed anyways. > >> >> --- >> >> src/share/vm/prims/jni_md.h >> src/share/vm/prims/jvm.h >> >> // Can not use CPU_HEADER() macro, as it appends .hpp >> >> can we not define a second form, eg CPU_HEADER_H, that appends.h >> instead? > I'll need one for OS, one for CPU, and each will be used only once. > So I figured not to do it. But probably I should do it to get is > similar everywhere. We actually need this as the simple arch names need not be mutually exclusive - eg arm and aarch64. Otherwise this needs to be an if-else construct in the correct order. ;-) Thanks, David ----- >> >> --- >> >> src/share/vm/runtime/os.hpp >> >> Should we convert setjmp.h include to: >> >> #ifndef _WINDOWS >> #include >> #endif >> #ifdef __APPLE__ >> ... >> #endif >> ? > Fixed. > > >> >> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the >> compiler itself? > I wondered about that, too. Therefore I defined WINDOWS in the > prototype webrev. Then I saw that our build is defining -D_WINDOWS *and* -DWIN32, > and removed it again using _WINDOWS instead. > Eventually both should be replaced by WINDOWS, but not in this change. > > >> --- >> >> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >> >> Don't understand the point of this: >> >> 28 #if defined(VM_LITTLE_ENDIAN) >> 29 // Aix is not littel endian. >> 30 #endif // VM_LITTLE_ENDIAN >> >> also typo: littel > I just copied the linux_ppc code and removed the unused implementation. > I wanted to document why there is this empty file. > > Best regards, > Goetz. > > > >> Thanks, >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 15. Juli 2016 11:11 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>> HI Kim, >>>>> >>>>> thanks for this version of the macros, it's working on all the platforms >>>>> I can build. >>>>> >>>>> Actually, I would prefer having the '_' in the macros and not on the >>>>> command line. This way, parts of the name construction are in >>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>>>> the search path is also in the makefile, and uses the very same string >>>>> as the file suffixes. (Without '_', one could include that in the macro, >> too.) >>>>> >>>>> But overall, I consider this a detail and am as fine with your solution >>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>> problems are avoided. >>>>> >>>>> Any more opinions whether the macros should be upper case? >>>> >>>> Yeah they probably should be. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>> wrote: >>>>>>> >>>>>>> Hi everybody, >>>>>>> >>>>>>> please take into account that these macros are only used within 20 >> lines >>>> of >>>>>>> the file macro.hpp. The code everybody needs to understand is >>>>>>> #include cpu_header(bytes) >>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>> bytes_.hpp. >>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>> >>>>>>> I really would appreciate if I don't have to spend days editing the >>>>>>> 12 lines that use SUB(). >>>>>>> >>>>>>> @Kim >>>>>>> I'm working on the s390 port, and posted my current progress claiming >>>>>>> that the biggest shared change I need to do is adding the #includes. >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>> July/023782.html >>>>>>> This arose the discussion about the includes. >>>>>>> Later I posted a prototype of what Volker proposed in that discussion >>>>>>> to that thread: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>> July/023934.html >>>>>>> which I now turned into a RFR. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> I think I see what happened to the email thread for me; it looks like one >> of >>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- >> runtime- >>>>>> dev, >>>>>> and I was not subscribed to the compiler list this morning. >>>>>> >>>>>> I like the idea, just quibbling over details. I've only reviewed >>>>>> macros.hpp so far; the rest looks like it can wait until the details >>>>>> are settled. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> src/share/vm/utilities/macros.hpp >>>>>> 470 // Helper macros to workaround existing #defines that spoil >>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>> >>>>>> This issue can be dodged by making the leading underscore part of the >>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, >> use >>>>>> instead >>>>>> >>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ >>>>>> >>>>>> Note the insertion of leading "_" for the values. >>>>>> >>>>>> Then the whole macro block can be written as >>>>>> >>>>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >>>>>> INCLUDE_SUFFIX_CPU) >>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>>>> INCLUDE_SUFFIX_OS) >>>>>> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, >>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>> >>>>>> #define cpu_header(basename) >>>> XSTR(cpu_header_stem(basename).hpp) >>>>>> #define cpu_header_inline(basename) >>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>> #define os_header(basename) >> XSTR(os_header_stem(basename).hpp) >>>>>> #define os_header_inline(basename) >>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>> #define os_cpu_header(basename) >>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>> #define os_cpu_header_inline(basename) >>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>> >>>>>> And SUB is no longer used... >>>>>> >>>>>> If some future build system wants brackets instead of strings, just >>>>>> replace XSTR(...) with <...>. >>>>>> >>>>>> We lose if _linux or _sparc (for example) are defined, but that's true >>>>>> for the webrev.01 code too. But note that underscore followed by a >>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>> >>>>>> BTW, my preference would be to use uppercase for the macro names. >> I >>>>>> don't know what others think about that. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>> From Alan.Burlison at oracle.com Mon Jul 18 10:13:54 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 18 Jul 2016 11:13:54 +0100 Subject: RFR: JDK-8160997 Solaris: deprecated and interfaces should be replaced In-Reply-To: <0fede411-2f22-7409-052f-3c4d202254ae@oracle.com> References: <57839D8A.9050108@oracle.com> <57867167.7020001@oracle.com> <4c8282d3-79ef-4b94-c2c0-4ba01c3240f9@oracle.com> <578744D5.7060300@oracle.com> <211137b4-28f2-9c60-7299-e2b19f0fd643@oracle.com> <5788C086.6050509@oracle.com> <5788E3C2.7070508@oracle.com> <0fede411-2f22-7409-052f-3c4d202254ae@oracle.com> Message-ID: <42e5c7d1-a962-7b8c-f1d9-51803e405a93@oracle.com> On 15/07/16 23:04, David Holmes wrote: >> Yes, agreed. It's a mess we are aiming to sort out but it isn't done yet. > > To be clear I was talking about the mess in the hotspot code :) Oh, I'm sure there's plenty of mess to go around ;-) -- Alan Burlison -- From goetz.lindenmaier at sap.com Mon Jul 18 10:21:53 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Jul 2016 10:21:53 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> Message-ID: <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> Hi David, > >> src/share/vm/prims/jni_md.h > >> src/share/vm/prims/jvm.h > >> > >> // Can not use CPU_HEADER() macro, as it appends .hpp > >> > >> can we not define a second form, eg CPU_HEADER_H, that appends.h > >> instead? > > I'll need one for OS, one for CPU, and each will be used only once. > > So I figured not to do it. But probably I should do it to get is > > similar everywhere. > > We actually need this as the simple arch names need not be mutually > exclusive - eg arm and aarch64. Otherwise this needs to be an if-else > construct in the correct order. ;-) They should be mutually exclusive, as they are set in CompileJvm.gmk in the same statement as the INCLUDE_SUFFIX_CPU: -D$(HOTSPOT_TARGET_CPU_DEFINE) Best regards, Goetz > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 18. Juli 2016 11:06 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > thanks for looking at all these files in more detail! > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Montag, 18. Juli 2016 08:03 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> Hi Goetz, > >> > >> Again thanks for tackling this! > >> > >> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I made a new webrev: > >>> - '_' is added in makefile > >>> - uses Kim's macros > >>> - macros are capitalized > >>> - more comments in macros.hpp > >>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.02/ > >> > >> Generally looks okay, a couple of clarifications and comments below. > >> > >> > >> make/gensrc/GensrcAdlc.gmk > >> > >> So the change from HOTSPOT_TARGET_CPU to > >> HOTSPOT_TARGET_CPU_ARCH only > >> affects the generated files right? > > Yes. > >> For our closed ports we still have > >> the _32/_64 source files in a common arch directory, but I don't think > >> that needs to be reflected in the generated files. (Sorry I haven't had > >> the time yet to apply this patch and see what needs to be changed on the > >> closed side - but will start that once I send this :).) > > If I run plain configure, it generates a directory that has the word size > > in it's name: > > linux-x86_64-normal-server-release > > If I configure --with-target-bits=32, it builds to > > linux-x86-normal-server-release, > > so I figured this should be fine. > > Yes generated files are fine. > > >> make/lib/CompileJvm.gmk > >> > >> Hmm but this change assumes no more _32/_64 header files if I read it > >> right ?? So I'll need a common file that dispatches internally for > >> 32-bit and 64-bit. > > Yes. > > There is a single file in cpu/x86 where this did not hold: stubRoutines > > But this was rather small. And there anyways was a common file > > that was included in both. > > > >> src/os/posix/vm/os_posix.cpp > >> > >> I'm wondering if we can use a similar trick to avoid this kind of > >> switch(OS) statement: > >> > >> #ifdef TARGET_OS_FAMILY_linux > >> Linux::ucontext_set_pc(ctx, pc); > >> #elif defined(TARGET_OS_FAMILY_solaris) > >> Solaris::ucontext_set_pc(ctx, pc); > >> ... > >> > >> ie something like: > >> > >> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >> > >> ? :) > > Hmm, I had to add the '_' to the string in TARGET_SO... > > Actually I think the implementation should be moved to > > os_linux.cpp/os_bsd.cpp etc. > > > >> > >> --- > >> > >> src/share/vm/code/nmethod.cpp > >> > >> Not clear why the platform include can simply be elided here ?? > > It already includes code/nativeInst.hpp, which is the umbrella header > > for all the platform files. > > > >> src/share/vm/jvmci/jvmciRuntime.cpp > >> > >> Shouldn't: > >> > >> ! #endif // !LP64 > >> > >> be: > >> > >> ! #endif // LP64 > > Well, it ends the #else part ... but fixed anyways. > > > >> > >> --- > >> > >> src/share/vm/prims/jni_md.h > >> src/share/vm/prims/jvm.h > >> > >> // Can not use CPU_HEADER() macro, as it appends .hpp > >> > >> can we not define a second form, eg CPU_HEADER_H, that appends.h > >> instead? > > I'll need one for OS, one for CPU, and each will be used only once. > > So I figured not to do it. But probably I should do it to get is > > similar everywhere. > > We actually need this as the simple arch names need not be mutually > exclusive - eg arm and aarch64. Otherwise this needs to be an if-else > construct in the correct order. ;-) > > Thanks, > David > ----- > > >> > >> --- > >> > >> src/share/vm/runtime/os.hpp > >> > >> Should we convert setjmp.h include to: > >> > >> #ifndef _WINDOWS > >> #include > >> #endif > >> #ifdef __APPLE__ > >> ... > >> #endif > >> ? > > Fixed. > > > > > >> > >> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the > >> compiler itself? > > I wondered about that, too. Therefore I defined WINDOWS in the > > prototype webrev. Then I saw that our build is defining -D_WINDOWS > *and* -DWIN32, > > and removed it again using _WINDOWS instead. > > Eventually both should be replaced by WINDOWS, but not in this change. > > > > > >> --- > >> > >> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >> > >> Don't understand the point of this: > >> > >> 28 #if defined(VM_LITTLE_ENDIAN) > >> 29 // Aix is not littel endian. > >> 30 #endif // VM_LITTLE_ENDIAN > >> > >> also typo: littel > > I just copied the linux_ppc code and removed the unused implementation. > > I wanted to document why there is this empty file. > > > > Best regards, > > Goetz. > > > > > > > >> Thanks, > >> David > >> ----- > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>> HI Kim, > >>>>> > >>>>> thanks for this version of the macros, it's working on all the platforms > >>>>> I can build. > >>>>> > >>>>> Actually, I would prefer having the '_' in the macros and not on the > >>>>> command line. This way, parts of the name construction are in > >>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing > >>>>> the search path is also in the makefile, and uses the very same string > >>>>> as the file suffixes. (Without '_', one could include that in the macro, > >> too.) > >>>>> > >>>>> But overall, I consider this a detail and am as fine with your solution > >>>>> as with the SUB() macros. What is better is that the linux=1 etc > >>>>> problems are avoided. > >>>>> > >>>>> Any more opinions whether the macros should be upper case? > >>>> > >>>> Yeah they probably should be. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>> To: Lindenmaier, Goetz > >>>>>> Cc: Andrew Haley ; hotspot-compiler- > >>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi everybody, > >>>>>>> > >>>>>>> please take into account that these macros are only used within 20 > >> lines > >>>> of > >>>>>>> the file macro.hpp. The code everybody needs to understand is > >>>>>>> #include cpu_header(bytes) > >>>>>>> which, in this example, is in file bytes.hpp and expands to > >>>>>> bytes_.hpp. > >>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > >>>>>>> > >>>>>>> I really would appreciate if I don't have to spend days editing the > >>>>>>> 12 lines that use SUB(). > >>>>>>> > >>>>>>> @Kim > >>>>>>> I'm working on the s390 port, and posted my current progress > claiming > >>>>>>> that the biggest shared change I need to do is adding the #includes. > >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>> July/023782.html > >>>>>>> This arose the discussion about the includes. > >>>>>>> Later I posted a prototype of what Volker proposed in that > discussion > >>>>>>> to that thread: > >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>> July/023934.html > >>>>>>> which I now turned into a RFR. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> I think I see what happened to the email thread for me; it looks like > one > >> of > >>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- > >> runtime- > >>>>>> dev, > >>>>>> and I was not subscribed to the compiler list this morning. > >>>>>> > >>>>>> I like the idea, just quibbling over details. I've only reviewed > >>>>>> macros.hpp so far; the rest looks like it can wait until the details > >>>>>> are settled. > >>>>>> > >>>>>> ------------------------------------------------------------------------------ > >>>>>> src/share/vm/utilities/macros.hpp > >>>>>> 470 // Helper macros to workaround existing #defines that spoil > >>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. > >>>>>> > >>>>>> This issue can be dodged by making the leading underscore part of > the > >>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > make/lib/CompileJvm.gmk, > >> use > >>>>>> instead > >>>>>> > >>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >>>>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > \ > >>>>>> > >>>>>> Note the insertion of leading "_" for the values. > >>>>>> > >>>>>> Then the whole macro block can be written as > >>>>>> > >>>>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, > >>>>>> INCLUDE_SUFFIX_CPU) > >>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, > >>>>>> INCLUDE_SUFFIX_OS) > >>>>>> #define os_cpu_header_stem(basename) > PASTE_TOKENS(basename, > >>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > >>>>>> > >>>>>> #define cpu_header(basename) > >>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>> #define cpu_header_inline(basename) > >>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>> #define os_header(basename) > >> XSTR(os_header_stem(basename).hpp) > >>>>>> #define os_header_inline(basename) > >>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>> #define os_cpu_header(basename) > >>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>> #define os_cpu_header_inline(basename) > >>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>> > >>>>>> And SUB is no longer used... > >>>>>> > >>>>>> If some future build system wants brackets instead of strings, just > >>>>>> replace XSTR(...) with <...>. > >>>>>> > >>>>>> We lose if _linux or _sparc (for example) are defined, but that's true > >>>>>> for the webrev.01 code too. But note that underscore followed by a > >>>>>> lowercase letter is not in the reserved word pattern for C/C++. > >>>>>> > >>>>>> BTW, my preference would be to use uppercase for the macro > names. > >> I > >>>>>> don't know what others think about that. > >>>>>> > >>>>>> ------------------------------------------------------------------------------ > >>>>> From david.holmes at oracle.com Mon Jul 18 12:12:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 22:12:33 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> Message-ID: <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Hi Goetz, On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > Hi David, > >>>> src/share/vm/prims/jni_md.h >>>> src/share/vm/prims/jvm.h >>>> >>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>> >>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>> instead? >>> I'll need one for OS, one for CPU, and each will be used only once. >>> So I figured not to do it. But probably I should do it to get is >>> similar everywhere. >> >> We actually need this as the simple arch names need not be mutually >> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >> construct in the correct order. ;-) > They should be mutually exclusive, as they are set in CompileJvm.gmk > in the same statement as the INCLUDE_SUFFIX_CPU: > -D$(HOTSPOT_TARGET_CPU_DEFINE) Unfortunately we also have -DARM coming in from the closed part of spec.gmk as we don't use AARCH64 for our port. So we get both defined and try to include two platform files. Not sure how to try and resolve this yet. Trying to understand what the role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not overriding it for our port - which I think is the current problem, but changing it may break something else. Thanks, David > Best regards, > Goetz > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 18. Juli 2016 11:06 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> thanks for looking at all these files in more detail! >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 18. Juli 2016 08:03 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> Hi Goetz, >>>> >>>> Again thanks for tackling this! >>>> >>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I made a new webrev: >>>>> - '_' is added in makefile >>>>> - uses Kim's macros >>>>> - macros are capitalized >>>>> - more comments in macros.hpp >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >> newPfmIncl/webrev.02/ >>>> >>>> Generally looks okay, a couple of clarifications and comments below. >>>> >>>> >>>> make/gensrc/GensrcAdlc.gmk >>>> >>>> So the change from HOTSPOT_TARGET_CPU to >>>> HOTSPOT_TARGET_CPU_ARCH only >>>> affects the generated files right? >>> Yes. >>>> For our closed ports we still have >>>> the _32/_64 source files in a common arch directory, but I don't think >>>> that needs to be reflected in the generated files. (Sorry I haven't had >>>> the time yet to apply this patch and see what needs to be changed on the >>>> closed side - but will start that once I send this :).) >>> If I run plain configure, it generates a directory that has the word size >>> in it's name: >>> linux-x86_64-normal-server-release >>> If I configure --with-target-bits=32, it builds to >>> linux-x86-normal-server-release, >>> so I figured this should be fine. >> >> Yes generated files are fine. >> >>>> make/lib/CompileJvm.gmk >>>> >>>> Hmm but this change assumes no more _32/_64 header files if I read it >>>> right ?? So I'll need a common file that dispatches internally for >>>> 32-bit and 64-bit. >>> Yes. >>> There is a single file in cpu/x86 where this did not hold: stubRoutines >>> But this was rather small. And there anyways was a common file >>> that was included in both. >>> >>>> src/os/posix/vm/os_posix.cpp >>>> >>>> I'm wondering if we can use a similar trick to avoid this kind of >>>> switch(OS) statement: >>>> >>>> #ifdef TARGET_OS_FAMILY_linux >>>> Linux::ucontext_set_pc(ctx, pc); >>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>> Solaris::ucontext_set_pc(ctx, pc); >>>> ... >>>> >>>> ie something like: >>>> >>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>> >>>> ? :) >>> Hmm, I had to add the '_' to the string in TARGET_SO... >>> Actually I think the implementation should be moved to >>> os_linux.cpp/os_bsd.cpp etc. >>> >>>> >>>> --- >>>> >>>> src/share/vm/code/nmethod.cpp >>>> >>>> Not clear why the platform include can simply be elided here ?? >>> It already includes code/nativeInst.hpp, which is the umbrella header >>> for all the platform files. >>> >>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>> >>>> Shouldn't: >>>> >>>> ! #endif // !LP64 >>>> >>>> be: >>>> >>>> ! #endif // LP64 >>> Well, it ends the #else part ... but fixed anyways. >>> >>>> >>>> --- >>>> >>>> src/share/vm/prims/jni_md.h >>>> src/share/vm/prims/jvm.h >>>> >>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>> >>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>> instead? >>> I'll need one for OS, one for CPU, and each will be used only once. >>> So I figured not to do it. But probably I should do it to get is >>> similar everywhere. >> >> We actually need this as the simple arch names need not be mutually >> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >> construct in the correct order. ;-) >> >> Thanks, >> David >> ----- >> >>>> >>>> --- >>>> >>>> src/share/vm/runtime/os.hpp >>>> >>>> Should we convert setjmp.h include to: >>>> >>>> #ifndef _WINDOWS >>>> #include >>>> #endif >>>> #ifdef __APPLE__ >>>> ... >>>> #endif >>>> ? >>> Fixed. >>> >>> >>>> >>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the >>>> compiler itself? >>> I wondered about that, too. Therefore I defined WINDOWS in the >>> prototype webrev. Then I saw that our build is defining -D_WINDOWS >> *and* -DWIN32, >>> and removed it again using _WINDOWS instead. >>> Eventually both should be replaced by WINDOWS, but not in this change. >>> >>> >>>> --- >>>> >>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>> >>>> Don't understand the point of this: >>>> >>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>> 29 // Aix is not littel endian. >>>> 30 #endif // VM_LITTLE_ENDIAN >>>> >>>> also typo: littel >>> I just copied the linux_ppc code and removed the unused implementation. >>> I wanted to document why there is this empty file. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>> HI Kim, >>>>>>> >>>>>>> thanks for this version of the macros, it's working on all the platforms >>>>>>> I can build. >>>>>>> >>>>>>> Actually, I would prefer having the '_' in the macros and not on the >>>>>>> command line. This way, parts of the name construction are in >>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>>>>>> the search path is also in the makefile, and uses the very same string >>>>>>> as the file suffixes. (Without '_', one could include that in the macro, >>>> too.) >>>>>>> >>>>>>> But overall, I consider this a detail and am as fine with your solution >>>>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>>>> problems are avoided. >>>>>>> >>>>>>> Any more opinions whether the macros should be upper case? >>>>>> >>>>>> Yeah they probably should be. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi everybody, >>>>>>>>> >>>>>>>>> please take into account that these macros are only used within 20 >>>> lines >>>>>> of >>>>>>>>> the file macro.hpp. The code everybody needs to understand is >>>>>>>>> #include cpu_header(bytes) >>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>> bytes_.hpp. >>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>>>> >>>>>>>>> I really would appreciate if I don't have to spend days editing the >>>>>>>>> 12 lines that use SUB(). >>>>>>>>> >>>>>>>>> @Kim >>>>>>>>> I'm working on the s390 port, and posted my current progress >> claiming >>>>>>>>> that the biggest shared change I need to do is adding the #includes. >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>> July/023782.html >>>>>>>>> This arose the discussion about the includes. >>>>>>>>> Later I posted a prototype of what Volker proposed in that >> discussion >>>>>>>>> to that thread: >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>> July/023934.html >>>>>>>>> which I now turned into a RFR. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> I think I see what happened to the email thread for me; it looks like >> one >>>> of >>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- >>>> runtime- >>>>>>>> dev, >>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>> >>>>>>>> I like the idea, just quibbling over details. I've only reviewed >>>>>>>> macros.hpp so far; the rest looks like it can wait until the details >>>>>>>> are settled. >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>> 470 // Helper macros to workaround existing #defines that spoil >>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>>>> >>>>>>>> This issue can be dodged by making the leading underscore part of >> the >>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >> make/lib/CompileJvm.gmk, >>>> use >>>>>>>> instead >>>>>>>> >>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >> \ >>>>>>>> >>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>> >>>>>>>> Then the whole macro block can be written as >>>>>>>> >>>>>>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>> #define os_cpu_header_stem(basename) >> PASTE_TOKENS(basename, >>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>>>> >>>>>>>> #define cpu_header(basename) >>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>> #define cpu_header_inline(basename) >>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>> #define os_header(basename) >>>> XSTR(os_header_stem(basename).hpp) >>>>>>>> #define os_header_inline(basename) >>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>> #define os_cpu_header(basename) >>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>> >>>>>>>> And SUB is no longer used... >>>>>>>> >>>>>>>> If some future build system wants brackets instead of strings, just >>>>>>>> replace XSTR(...) with <...>. >>>>>>>> >>>>>>>> We lose if _linux or _sparc (for example) are defined, but that's true >>>>>>>> for the webrev.01 code too. But note that underscore followed by a >>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>>>> >>>>>>>> BTW, my preference would be to use uppercase for the macro >> names. >>>> I >>>>>>>> don't know what others think about that. >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>> From david.holmes at oracle.com Mon Jul 18 12:16:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 22:16:17 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Message-ID: Backing up a step ... On 18/07/2016 10:12 PM, David Holmes wrote: > Hi Goetz, > > On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >>>>> src/share/vm/prims/jni_md.h >>>>> src/share/vm/prims/jvm.h >>>>> >>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>> >>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>> instead? >>>> I'll need one for OS, one for CPU, and each will be used only once. >>>> So I figured not to do it. But probably I should do it to get is >>>> similar everywhere. >>> >>> We actually need this as the simple arch names need not be mutually >>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>> construct in the correct order. ;-) >> They should be mutually exclusive, as they are set in CompileJvm.gmk >> in the same statement as the INCLUDE_SUFFIX_CPU: >> -D$(HOTSPOT_TARGET_CPU_DEFINE) Why do you use HOTSPOT_TARGET_CPU_DEFINE? I would have expected OPENJDK_TARGET_CPU. (There are still far too many "arch" related variables in the build :(.) Thanks, David > Unfortunately we also have -DARM coming in from the closed part of > spec.gmk as we don't use AARCH64 for our port. So we get both defined > and try to include two platform files. > > Not sure how to try and resolve this yet. Trying to understand what the > role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not > overriding it for our port - which I think is the current problem, but > changing it may break something else. > > Thanks, > David > > >> Best regards, >> Goetz >> >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Montag, 18. Juli 2016 11:06 >>> To: Lindenmaier, Goetz ; Kim Barrett >>> >>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>> >>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> thanks for looking at all these files in more detail! >>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>> >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>> >>>>> Hi Goetz, >>>>> >>>>> Again thanks for tackling this! >>>>> >>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I made a new webrev: >>>>>> - '_' is added in makefile >>>>>> - uses Kim's macros >>>>>> - macros are capitalized >>>>>> - more comments in macros.hpp >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>> newPfmIncl/webrev.02/ >>>>> >>>>> Generally looks okay, a couple of clarifications and comments below. >>>>> >>>>> >>>>> make/gensrc/GensrcAdlc.gmk >>>>> >>>>> So the change from HOTSPOT_TARGET_CPU to >>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>> affects the generated files right? >>>> Yes. >>>>> For our closed ports we still have >>>>> the _32/_64 source files in a common arch directory, but I don't think >>>>> that needs to be reflected in the generated files. (Sorry I haven't >>>>> had >>>>> the time yet to apply this patch and see what needs to be changed >>>>> on the >>>>> closed side - but will start that once I send this :).) >>>> If I run plain configure, it generates a directory that has the word >>>> size >>>> in it's name: >>>> linux-x86_64-normal-server-release >>>> If I configure --with-target-bits=32, it builds to >>>> linux-x86-normal-server-release, >>>> so I figured this should be fine. >>> >>> Yes generated files are fine. >>> >>>>> make/lib/CompileJvm.gmk >>>>> >>>>> Hmm but this change assumes no more _32/_64 header files if I read it >>>>> right ?? So I'll need a common file that dispatches internally for >>>>> 32-bit and 64-bit. >>>> Yes. >>>> There is a single file in cpu/x86 where this did not hold: stubRoutines >>>> But this was rather small. And there anyways was a common file >>>> that was included in both. >>>> >>>>> src/os/posix/vm/os_posix.cpp >>>>> >>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>> switch(OS) statement: >>>>> >>>>> #ifdef TARGET_OS_FAMILY_linux >>>>> Linux::ucontext_set_pc(ctx, pc); >>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>> ... >>>>> >>>>> ie something like: >>>>> >>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>> >>>>> ? :) >>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>> Actually I think the implementation should be moved to >>>> os_linux.cpp/os_bsd.cpp etc. >>>> >>>>> >>>>> --- >>>>> >>>>> src/share/vm/code/nmethod.cpp >>>>> >>>>> Not clear why the platform include can simply be elided here ?? >>>> It already includes code/nativeInst.hpp, which is the umbrella header >>>> for all the platform files. >>>> >>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>> >>>>> Shouldn't: >>>>> >>>>> ! #endif // !LP64 >>>>> >>>>> be: >>>>> >>>>> ! #endif // LP64 >>>> Well, it ends the #else part ... but fixed anyways. >>>> >>>>> >>>>> --- >>>>> >>>>> src/share/vm/prims/jni_md.h >>>>> src/share/vm/prims/jvm.h >>>>> >>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>> >>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>> instead? >>>> I'll need one for OS, one for CPU, and each will be used only once. >>>> So I figured not to do it. But probably I should do it to get is >>>> similar everywhere. >>> >>> We actually need this as the simple arch names need not be mutually >>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>> construct in the correct order. ;-) >>> >>> Thanks, >>> David >>> ----- >>> >>>>> >>>>> --- >>>>> >>>>> src/share/vm/runtime/os.hpp >>>>> >>>>> Should we convert setjmp.h include to: >>>>> >>>>> #ifndef _WINDOWS >>>>> #include >>>>> #endif >>>>> #ifdef __APPLE__ >>>>> ... >>>>> #endif >>>>> ? >>>> Fixed. >>>> >>>> >>>>> >>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the >>>>> compiler itself? >>>> I wondered about that, too. Therefore I defined WINDOWS in the >>>> prototype webrev. Then I saw that our build is defining -D_WINDOWS >>> *and* -DWIN32, >>>> and removed it again using _WINDOWS instead. >>>> Eventually both should be replaced by WINDOWS, but not in this change. >>>> >>>> >>>>> --- >>>>> >>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>> >>>>> Don't understand the point of this: >>>>> >>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>> 29 // Aix is not littel endian. >>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>> >>>>> also typo: littel >>>> I just copied the linux_ppc code and removed the unused implementation. >>>> I wanted to document why there is this empty file. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>> >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>> >>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>> HI Kim, >>>>>>>> >>>>>>>> thanks for this version of the macros, it's working on all the >>>>>>>> platforms >>>>>>>> I can build. >>>>>>>> >>>>>>>> Actually, I would prefer having the '_' in the macros and not on >>>>>>>> the >>>>>>>> command line. This way, parts of the name construction are in >>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>>>>>>> the search path is also in the makefile, and uses the very same >>>>>>>> string >>>>>>>> as the file suffixes. (Without '_', one could include that in >>>>>>>> the macro, >>>>> too.) >>>>>>>> >>>>>>>> But overall, I consider this a detail and am as fine with your >>>>>>>> solution >>>>>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>>>>> problems are avoided. >>>>>>>> >>>>>>>> Any more opinions whether the macros should be upper case? >>>>>>> >>>>>>> Yeah they probably should be. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi everybody, >>>>>>>>>> >>>>>>>>>> please take into account that these macros are only used >>>>>>>>>> within 20 >>>>> lines >>>>>>> of >>>>>>>>>> the file macro.hpp. The code everybody needs to understand is >>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>> bytes_.hpp. >>>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>>>>> >>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>> editing the >>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>> >>>>>>>>>> @Kim >>>>>>>>>> I'm working on the s390 port, and posted my current progress >>> claiming >>>>>>>>>> that the biggest shared change I need to do is adding the >>>>>>>>>> #includes. >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>> July/023782.html >>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>> Later I posted a prototype of what Volker proposed in that >>> discussion >>>>>>>>>> to that thread: >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>> July/023934.html >>>>>>>>>> which I now turned into a RFR. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> I think I see what happened to the email thread for me; it >>>>>>>>> looks like >>> one >>>>> of >>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- >>>>> runtime- >>>>>>>>> dev, >>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>> >>>>>>>>> I like the idea, just quibbling over details. I've only reviewed >>>>>>>>> macros.hpp so far; the rest looks like it can wait until the >>>>>>>>> details >>>>>>>>> are settled. >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>> 470 // Helper macros to workaround existing #defines that spoil >>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>>>>> >>>>>>>>> This issue can be dodged by making the leading underscore part of >>> the >>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>> make/lib/CompileJvm.gmk, >>>>> use >>>>>>>>> instead >>>>>>>>> >>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>> \ >>>>>>>>> >>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>> >>>>>>>>> Then the whole macro block can be written as >>>>>>>>> >>>>>>>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>> #define os_cpu_header_stem(basename) >>> PASTE_TOKENS(basename, >>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>>>>> >>>>>>>>> #define cpu_header(basename) >>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>> #define os_header(basename) >>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>> #define os_header_inline(basename) >>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>> #define os_cpu_header(basename) >>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>> >>>>>>>>> And SUB is no longer used... >>>>>>>>> >>>>>>>>> If some future build system wants brackets instead of strings, >>>>>>>>> just >>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>> >>>>>>>>> We lose if _linux or _sparc (for example) are defined, but >>>>>>>>> that's true >>>>>>>>> for the webrev.01 code too. But note that underscore followed >>>>>>>>> by a >>>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>>>>> >>>>>>>>> BTW, my preference would be to use uppercase for the macro >>> names. >>>>> I >>>>>>>>> don't know what others think about that. >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> >>>>>>>> From goetz.lindenmaier at sap.com Mon Jul 18 12:18:02 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Jul 2016 12:18:02 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Message-ID: Hi David, I'll introduce CPU_HEADER_H, but actually this should be fixed in the closed code. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Montag, 18. Juli 2016 14:13 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Hi Goetz, > > On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > >>>> src/share/vm/prims/jni_md.h > >>>> src/share/vm/prims/jvm.h > >>>> > >>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>> > >>>> can we not define a second form, eg CPU_HEADER_H, that appends.h > >>>> instead? > >>> I'll need one for OS, one for CPU, and each will be used only once. > >>> So I figured not to do it. But probably I should do it to get is > >>> similar everywhere. > >> > >> We actually need this as the simple arch names need not be mutually > >> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else > >> construct in the correct order. ;-) > > They should be mutually exclusive, as they are set in CompileJvm.gmk > > in the same statement as the INCLUDE_SUFFIX_CPU: > > -D$(HOTSPOT_TARGET_CPU_DEFINE) > > Unfortunately we also have -DARM coming in from the closed part of > spec.gmk as we don't use AARCH64 for our port. So we get both defined > and try to include two platform files. > > Not sure how to try and resolve this yet. Trying to understand what the > role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not > overriding it for our port - which I think is the current problem, but > changing it may break something else. > > Thanks, > David > > > > Best regards, > > Goetz > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Montag, 18. Juli 2016 11:06 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> thanks for looking at all these files in more detail! > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Montag, 18. Juli 2016 08:03 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Hi Goetz, > >>>> > >>>> Again thanks for tackling this! > >>>> > >>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I made a new webrev: > >>>>> - '_' is added in makefile > >>>>> - uses Kim's macros > >>>>> - macros are capitalized > >>>>> - more comments in macros.hpp > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >> newPfmIncl/webrev.02/ > >>>> > >>>> Generally looks okay, a couple of clarifications and comments below. > >>>> > >>>> > >>>> make/gensrc/GensrcAdlc.gmk > >>>> > >>>> So the change from HOTSPOT_TARGET_CPU to > >>>> HOTSPOT_TARGET_CPU_ARCH only > >>>> affects the generated files right? > >>> Yes. > >>>> For our closed ports we still have > >>>> the _32/_64 source files in a common arch directory, but I don't think > >>>> that needs to be reflected in the generated files. (Sorry I haven't had > >>>> the time yet to apply this patch and see what needs to be changed on > the > >>>> closed side - but will start that once I send this :).) > >>> If I run plain configure, it generates a directory that has the word size > >>> in it's name: > >>> linux-x86_64-normal-server-release > >>> If I configure --with-target-bits=32, it builds to > >>> linux-x86-normal-server-release, > >>> so I figured this should be fine. > >> > >> Yes generated files are fine. > >> > >>>> make/lib/CompileJvm.gmk > >>>> > >>>> Hmm but this change assumes no more _32/_64 header files if I read it > >>>> right ?? So I'll need a common file that dispatches internally for > >>>> 32-bit and 64-bit. > >>> Yes. > >>> There is a single file in cpu/x86 where this did not hold: stubRoutines > >>> But this was rather small. And there anyways was a common file > >>> that was included in both. > >>> > >>>> src/os/posix/vm/os_posix.cpp > >>>> > >>>> I'm wondering if we can use a similar trick to avoid this kind of > >>>> switch(OS) statement: > >>>> > >>>> #ifdef TARGET_OS_FAMILY_linux > >>>> Linux::ucontext_set_pc(ctx, pc); > >>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>> Solaris::ucontext_set_pc(ctx, pc); > >>>> ... > >>>> > >>>> ie something like: > >>>> > >>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>> > >>>> ? :) > >>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>> Actually I think the implementation should be moved to > >>> os_linux.cpp/os_bsd.cpp etc. > >>> > >>>> > >>>> --- > >>>> > >>>> src/share/vm/code/nmethod.cpp > >>>> > >>>> Not clear why the platform include can simply be elided here ?? > >>> It already includes code/nativeInst.hpp, which is the umbrella header > >>> for all the platform files. > >>> > >>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>> > >>>> Shouldn't: > >>>> > >>>> ! #endif // !LP64 > >>>> > >>>> be: > >>>> > >>>> ! #endif // LP64 > >>> Well, it ends the #else part ... but fixed anyways. > >>> > >>>> > >>>> --- > >>>> > >>>> src/share/vm/prims/jni_md.h > >>>> src/share/vm/prims/jvm.h > >>>> > >>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>> > >>>> can we not define a second form, eg CPU_HEADER_H, that appends.h > >>>> instead? > >>> I'll need one for OS, one for CPU, and each will be used only once. > >>> So I figured not to do it. But probably I should do it to get is > >>> similar everywhere. > >> > >> We actually need this as the simple arch names need not be mutually > >> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else > >> construct in the correct order. ;-) > >> > >> Thanks, > >> David > >> ----- > >> > >>>> > >>>> --- > >>>> > >>>> src/share/vm/runtime/os.hpp > >>>> > >>>> Should we convert setjmp.h include to: > >>>> > >>>> #ifndef _WINDOWS > >>>> #include > >>>> #endif > >>>> #ifdef __APPLE__ > >>>> ... > >>>> #endif > >>>> ? > >>> Fixed. > >>> > >>> > >>>> > >>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from > the > >>>> compiler itself? > >>> I wondered about that, too. Therefore I defined WINDOWS in the > >>> prototype webrev. Then I saw that our build is defining -D_WINDOWS > >> *and* -DWIN32, > >>> and removed it again using _WINDOWS instead. > >>> Eventually both should be replaced by WINDOWS, but not in this change. > >>> > >>> > >>>> --- > >>>> > >>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>> > >>>> Don't understand the point of this: > >>>> > >>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>> 29 // Aix is not littel endian. > >>>> 30 #endif // VM_LITTLE_ENDIAN > >>>> > >>>> also typo: littel > >>> I just copied the linux_ppc code and removed the unused > implementation. > >>> I wanted to document why there is this empty file. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>> HI Kim, > >>>>>>> > >>>>>>> thanks for this version of the macros, it's working on all the > platforms > >>>>>>> I can build. > >>>>>>> > >>>>>>> Actually, I would prefer having the '_' in the macros and not on the > >>>>>>> command line. This way, parts of the name construction are in > >>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing > >>>>>>> the search path is also in the makefile, and uses the very same > string > >>>>>>> as the file suffixes. (Without '_', one could include that in the > macro, > >>>> too.) > >>>>>>> > >>>>>>> But overall, I consider this a detail and am as fine with your solution > >>>>>>> as with the SUB() macros. What is better is that the linux=1 etc > >>>>>>> problems are avoided. > >>>>>>> > >>>>>>> Any more opinions whether the macros should be upper case? > >>>>>> > >>>>>> Yeah they probably should be. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>> To: Lindenmaier, Goetz > >>>>>>>> Cc: Andrew Haley ; hotspot-compiler- > >>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi everybody, > >>>>>>>>> > >>>>>>>>> please take into account that these macros are only used within > 20 > >>>> lines > >>>>>> of > >>>>>>>>> the file macro.hpp. The code everybody needs to understand is > >>>>>>>>> #include cpu_header(bytes) > >>>>>>>>> which, in this example, is in file bytes.hpp and expands to > >>>>>>>> bytes_.hpp. > >>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > >>>>>>>>> > >>>>>>>>> I really would appreciate if I don't have to spend days editing the > >>>>>>>>> 12 lines that use SUB(). > >>>>>>>>> > >>>>>>>>> @Kim > >>>>>>>>> I'm working on the s390 port, and posted my current progress > >> claiming > >>>>>>>>> that the biggest shared change I need to do is adding the > #includes. > >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>>>> July/023782.html > >>>>>>>>> This arose the discussion about the includes. > >>>>>>>>> Later I posted a prototype of what Volker proposed in that > >> discussion > >>>>>>>>> to that thread: > >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>>>> July/023934.html > >>>>>>>>> which I now turned into a RFR. > >>>>>>>> > >>>>>>>> Thanks. > >>>>>>>> > >>>>>>>> I think I see what happened to the email thread for me; it looks > like > >> one > >>>> of > >>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- > >>>> runtime- > >>>>>>>> dev, > >>>>>>>> and I was not subscribed to the compiler list this morning. > >>>>>>>> > >>>>>>>> I like the idea, just quibbling over details. I've only reviewed > >>>>>>>> macros.hpp so far; the rest looks like it can wait until the details > >>>>>>>> are settled. > >>>>>>>> > >>>>>>>> ------------------------------------------------------------------------------ > >>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>> 470 // Helper macros to workaround existing #defines that spoil > >>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. > >>>>>>>> > >>>>>>>> This issue can be dodged by making the leading underscore part > of > >> the > >>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >> make/lib/CompileJvm.gmk, > >>>> use > >>>>>>>> instead > >>>>>>>> > >>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >>>>>>>> 68 - > DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >> \ > >>>>>>>> > >>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>> > >>>>>>>> Then the whole macro block can be written as > >>>>>>>> > >>>>>>>> #define cpu_header_stem(basename) > PASTE_TOKENS(basename, > >>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, > >>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>> #define os_cpu_header_stem(basename) > >> PASTE_TOKENS(basename, > >>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > >>>>>>>> > >>>>>>>> #define cpu_header(basename) > >>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>> #define cpu_header_inline(basename) > >>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>> #define os_header(basename) > >>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>> #define os_header_inline(basename) > >>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>> #define os_cpu_header(basename) > >>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>> > >>>>>>>> And SUB is no longer used... > >>>>>>>> > >>>>>>>> If some future build system wants brackets instead of strings, just > >>>>>>>> replace XSTR(...) with <...>. > >>>>>>>> > >>>>>>>> We lose if _linux or _sparc (for example) are defined, but that's > true > >>>>>>>> for the webrev.01 code too. But note that underscore followed > by a > >>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. > >>>>>>>> > >>>>>>>> BTW, my preference would be to use uppercase for the macro > >> names. > >>>> I > >>>>>>>> don't know what others think about that. > >>>>>>>> > >>>>>>>> ------------------------------------------------------------------------------ > >>>>>>> From david.holmes at oracle.com Mon Jul 18 12:20:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 22:20:06 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Message-ID: Retracting my backup a step ... On 18/07/2016 10:16 PM, David Holmes wrote: > Backing up a step ... > > On 18/07/2016 10:12 PM, David Holmes wrote: >> Hi Goetz, >> >> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>>>>> src/share/vm/prims/jni_md.h >>>>>> src/share/vm/prims/jvm.h >>>>>> >>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>> >>>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>>> instead? >>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>> So I figured not to do it. But probably I should do it to get is >>>>> similar everywhere. >>>> >>>> We actually need this as the simple arch names need not be mutually >>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>> construct in the correct order. ;-) >>> They should be mutually exclusive, as they are set in CompileJvm.gmk >>> in the same statement as the INCLUDE_SUFFIX_CPU: >>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > > Why do you use HOTSPOT_TARGET_CPU_DEFINE? I would have expected > OPENJDK_TARGET_CPU. (There are still far too many "arch" related > variables in the build :(.) That -D is already present, you simply use it as the guard. David > Thanks, > David > >> Unfortunately we also have -DARM coming in from the closed part of >> spec.gmk as we don't use AARCH64 for our port. So we get both defined >> and try to include two platform files. >> >> Not sure how to try and resolve this yet. Trying to understand what the >> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not >> overriding it for our port - which I think is the current problem, but >> changing it may break something else. >> >> Thanks, >> David >> >> >>> Best regards, >>> Goetz >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 18. Juli 2016 11:06 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> thanks for looking at all these files in more detail! >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Again thanks for tackling this! >>>>>> >>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I made a new webrev: >>>>>>> - '_' is added in makefile >>>>>>> - uses Kim's macros >>>>>>> - macros are capitalized >>>>>>> - more comments in macros.hpp >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>> newPfmIncl/webrev.02/ >>>>>> >>>>>> Generally looks okay, a couple of clarifications and comments below. >>>>>> >>>>>> >>>>>> make/gensrc/GensrcAdlc.gmk >>>>>> >>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>> affects the generated files right? >>>>> Yes. >>>>>> For our closed ports we still have >>>>>> the _32/_64 source files in a common arch directory, but I don't >>>>>> think >>>>>> that needs to be reflected in the generated files. (Sorry I haven't >>>>>> had >>>>>> the time yet to apply this patch and see what needs to be changed >>>>>> on the >>>>>> closed side - but will start that once I send this :).) >>>>> If I run plain configure, it generates a directory that has the word >>>>> size >>>>> in it's name: >>>>> linux-x86_64-normal-server-release >>>>> If I configure --with-target-bits=32, it builds to >>>>> linux-x86-normal-server-release, >>>>> so I figured this should be fine. >>>> >>>> Yes generated files are fine. >>>> >>>>>> make/lib/CompileJvm.gmk >>>>>> >>>>>> Hmm but this change assumes no more _32/_64 header files if I read it >>>>>> right ?? So I'll need a common file that dispatches internally for >>>>>> 32-bit and 64-bit. >>>>> Yes. >>>>> There is a single file in cpu/x86 where this did not hold: >>>>> stubRoutines >>>>> But this was rather small. And there anyways was a common file >>>>> that was included in both. >>>>> >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> >>>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>>> switch(OS) statement: >>>>>> >>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>> ... >>>>>> >>>>>> ie something like: >>>>>> >>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>> >>>>>> ? :) >>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>> Actually I think the implementation should be moved to >>>>> os_linux.cpp/os_bsd.cpp etc. >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/code/nmethod.cpp >>>>>> >>>>>> Not clear why the platform include can simply be elided here ?? >>>>> It already includes code/nativeInst.hpp, which is the umbrella header >>>>> for all the platform files. >>>>> >>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>> >>>>>> Shouldn't: >>>>>> >>>>>> ! #endif // !LP64 >>>>>> >>>>>> be: >>>>>> >>>>>> ! #endif // LP64 >>>>> Well, it ends the #else part ... but fixed anyways. >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/prims/jni_md.h >>>>>> src/share/vm/prims/jvm.h >>>>>> >>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>> >>>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>>> instead? >>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>> So I figured not to do it. But probably I should do it to get is >>>>> similar everywhere. >>>> >>>> We actually need this as the simple arch names need not be mutually >>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>> construct in the correct order. ;-) >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/runtime/os.hpp >>>>>> >>>>>> Should we convert setjmp.h include to: >>>>>> >>>>>> #ifndef _WINDOWS >>>>>> #include >>>>>> #endif >>>>>> #ifdef __APPLE__ >>>>>> ... >>>>>> #endif >>>>>> ? >>>>> Fixed. >>>>> >>>>> >>>>>> >>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from the >>>>>> compiler itself? >>>>> I wondered about that, too. Therefore I defined WINDOWS in the >>>>> prototype webrev. Then I saw that our build is defining -D_WINDOWS >>>> *and* -DWIN32, >>>>> and removed it again using _WINDOWS instead. >>>>> Eventually both should be replaced by WINDOWS, but not in this change. >>>>> >>>>> >>>>>> --- >>>>>> >>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>> >>>>>> Don't understand the point of this: >>>>>> >>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>> 29 // Aix is not littel endian. >>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>> >>>>>> also typo: littel >>>>> I just copied the linux_ppc code and removed the unused >>>>> implementation. >>>>> I wanted to document why there is this empty file. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>> HI Kim, >>>>>>>>> >>>>>>>>> thanks for this version of the macros, it's working on all the >>>>>>>>> platforms >>>>>>>>> I can build. >>>>>>>>> >>>>>>>>> Actually, I would prefer having the '_' in the macros and not on >>>>>>>>> the >>>>>>>>> command line. This way, parts of the name construction are in >>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>>>>>>>> the search path is also in the makefile, and uses the very same >>>>>>>>> string >>>>>>>>> as the file suffixes. (Without '_', one could include that in >>>>>>>>> the macro, >>>>>> too.) >>>>>>>>> >>>>>>>>> But overall, I consider this a detail and am as fine with your >>>>>>>>> solution >>>>>>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>>>>>> problems are avoided. >>>>>>>>> >>>>>>>>> Any more opinions whether the macros should be upper case? >>>>>>>> >>>>>>>> Yeah they probably should be. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> please take into account that these macros are only used >>>>>>>>>>> within 20 >>>>>> lines >>>>>>>> of >>>>>>>>>>> the file macro.hpp. The code everybody needs to understand is >>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>>> bytes_.hpp. >>>>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>>>>>> >>>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>>> editing the >>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>> >>>>>>>>>>> @Kim >>>>>>>>>>> I'm working on the s390 port, and posted my current progress >>>> claiming >>>>>>>>>>> that the biggest shared change I need to do is adding the >>>>>>>>>>> #includes. >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>> July/023782.html >>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>> Later I posted a prototype of what Volker proposed in that >>>> discussion >>>>>>>>>>> to that thread: >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>> July/023934.html >>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> I think I see what happened to the email thread for me; it >>>>>>>>>> looks like >>>> one >>>>>> of >>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- >>>>>> runtime- >>>>>>>>>> dev, >>>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>>> >>>>>>>>>> I like the idea, just quibbling over details. I've only reviewed >>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the >>>>>>>>>> details >>>>>>>>>> are settled. >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>> 470 // Helper macros to workaround existing #defines that spoil >>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>>>>>> >>>>>>>>>> This issue can be dodged by making the leading underscore part of >>>> the >>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>> make/lib/CompileJvm.gmk, >>>>>> use >>>>>>>>>> instead >>>>>>>>>> >>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>> \ >>>>>>>>>> >>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>> >>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>> >>>>>>>>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>> #define os_cpu_header_stem(basename) >>>> PASTE_TOKENS(basename, >>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>>>>>> >>>>>>>>>> #define cpu_header(basename) >>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>> #define os_header(basename) >>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>> >>>>>>>>>> And SUB is no longer used... >>>>>>>>>> >>>>>>>>>> If some future build system wants brackets instead of strings, >>>>>>>>>> just >>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>> >>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but >>>>>>>>>> that's true >>>>>>>>>> for the webrev.01 code too. But note that underscore followed >>>>>>>>>> by a >>>>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>>>>>> >>>>>>>>>> BTW, my preference would be to use uppercase for the macro >>>> names. >>>>>> I >>>>>>>>>> don't know what others think about that. >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> From david.holmes at oracle.com Mon Jul 18 12:23:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jul 2016 22:23:22 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Message-ID: On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > Hi David, > > I'll introduce CPU_HEADER_H, but actually this should be fixed > in the closed code. Bear with me, I'm trying to figure out how to do just that. :) The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef is not going to work for our closed ports, unless I change that value to match the open naming scheme. But that in turn will lead to other problems as we also need that value the way it is currently defined. I'll tackle this again in the morning when I'm fresher. Thanks, David > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 18. Juli 2016 14:13 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> Hi Goetz, >> >> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>>>>> src/share/vm/prims/jni_md.h >>>>>> src/share/vm/prims/jvm.h >>>>>> >>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>> >>>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>>> instead? >>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>> So I figured not to do it. But probably I should do it to get is >>>>> similar everywhere. >>>> >>>> We actually need this as the simple arch names need not be mutually >>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>> construct in the correct order. ;-) >>> They should be mutually exclusive, as they are set in CompileJvm.gmk >>> in the same statement as the INCLUDE_SUFFIX_CPU: >>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >> >> Unfortunately we also have -DARM coming in from the closed part of >> spec.gmk as we don't use AARCH64 for our port. So we get both defined >> and try to include two platform files. >> >> Not sure how to try and resolve this yet. Trying to understand what the >> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not >> overriding it for our port - which I think is the current problem, but >> changing it may break something else. >> >> Thanks, >> David >> >> >>> Best regards, >>> Goetz >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 18. Juli 2016 11:06 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> thanks for looking at all these files in more detail! >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> Again thanks for tackling this! >>>>>> >>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I made a new webrev: >>>>>>> - '_' is added in makefile >>>>>>> - uses Kim's macros >>>>>>> - macros are capitalized >>>>>>> - more comments in macros.hpp >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>> newPfmIncl/webrev.02/ >>>>>> >>>>>> Generally looks okay, a couple of clarifications and comments below. >>>>>> >>>>>> >>>>>> make/gensrc/GensrcAdlc.gmk >>>>>> >>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>> affects the generated files right? >>>>> Yes. >>>>>> For our closed ports we still have >>>>>> the _32/_64 source files in a common arch directory, but I don't think >>>>>> that needs to be reflected in the generated files. (Sorry I haven't had >>>>>> the time yet to apply this patch and see what needs to be changed on >> the >>>>>> closed side - but will start that once I send this :).) >>>>> If I run plain configure, it generates a directory that has the word size >>>>> in it's name: >>>>> linux-x86_64-normal-server-release >>>>> If I configure --with-target-bits=32, it builds to >>>>> linux-x86-normal-server-release, >>>>> so I figured this should be fine. >>>> >>>> Yes generated files are fine. >>>> >>>>>> make/lib/CompileJvm.gmk >>>>>> >>>>>> Hmm but this change assumes no more _32/_64 header files if I read it >>>>>> right ?? So I'll need a common file that dispatches internally for >>>>>> 32-bit and 64-bit. >>>>> Yes. >>>>> There is a single file in cpu/x86 where this did not hold: stubRoutines >>>>> But this was rather small. And there anyways was a common file >>>>> that was included in both. >>>>> >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> >>>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>>> switch(OS) statement: >>>>>> >>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>> ... >>>>>> >>>>>> ie something like: >>>>>> >>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>> >>>>>> ? :) >>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>> Actually I think the implementation should be moved to >>>>> os_linux.cpp/os_bsd.cpp etc. >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/code/nmethod.cpp >>>>>> >>>>>> Not clear why the platform include can simply be elided here ?? >>>>> It already includes code/nativeInst.hpp, which is the umbrella header >>>>> for all the platform files. >>>>> >>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>> >>>>>> Shouldn't: >>>>>> >>>>>> ! #endif // !LP64 >>>>>> >>>>>> be: >>>>>> >>>>>> ! #endif // LP64 >>>>> Well, it ends the #else part ... but fixed anyways. >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/prims/jni_md.h >>>>>> src/share/vm/prims/jvm.h >>>>>> >>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>> >>>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>>> instead? >>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>> So I figured not to do it. But probably I should do it to get is >>>>> similar everywhere. >>>> >>>> We actually need this as the simple arch names need not be mutually >>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>> construct in the correct order. ;-) >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/runtime/os.hpp >>>>>> >>>>>> Should we convert setjmp.h include to: >>>>>> >>>>>> #ifndef _WINDOWS >>>>>> #include >>>>>> #endif >>>>>> #ifdef __APPLE__ >>>>>> ... >>>>>> #endif >>>>>> ? >>>>> Fixed. >>>>> >>>>> >>>>>> >>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from >> the >>>>>> compiler itself? >>>>> I wondered about that, too. Therefore I defined WINDOWS in the >>>>> prototype webrev. Then I saw that our build is defining -D_WINDOWS >>>> *and* -DWIN32, >>>>> and removed it again using _WINDOWS instead. >>>>> Eventually both should be replaced by WINDOWS, but not in this change. >>>>> >>>>> >>>>>> --- >>>>>> >>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>> >>>>>> Don't understand the point of this: >>>>>> >>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>> 29 // Aix is not littel endian. >>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>> >>>>>> also typo: littel >>>>> I just copied the linux_ppc code and removed the unused >> implementation. >>>>> I wanted to document why there is this empty file. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>> HI Kim, >>>>>>>>> >>>>>>>>> thanks for this version of the macros, it's working on all the >> platforms >>>>>>>>> I can build. >>>>>>>>> >>>>>>>>> Actually, I would prefer having the '_' in the macros and not on the >>>>>>>>> command line. This way, parts of the name construction are in >>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>>>>>>>> the search path is also in the makefile, and uses the very same >> string >>>>>>>>> as the file suffixes. (Without '_', one could include that in the >> macro, >>>>>> too.) >>>>>>>>> >>>>>>>>> But overall, I consider this a detail and am as fine with your solution >>>>>>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>>>>>> problems are avoided. >>>>>>>>> >>>>>>>>> Any more opinions whether the macros should be upper case? >>>>>>>> >>>>>>>> Yeah they probably should be. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> please take into account that these macros are only used within >> 20 >>>>>> lines >>>>>>>> of >>>>>>>>>>> the file macro.hpp. The code everybody needs to understand is >>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>>> bytes_.hpp. >>>>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>>>>>> >>>>>>>>>>> I really would appreciate if I don't have to spend days editing the >>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>> >>>>>>>>>>> @Kim >>>>>>>>>>> I'm working on the s390 port, and posted my current progress >>>> claiming >>>>>>>>>>> that the biggest shared change I need to do is adding the >> #includes. >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>> July/023782.html >>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>> Later I posted a prototype of what Volker proposed in that >>>> discussion >>>>>>>>>>> to that thread: >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>> July/023934.html >>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> I think I see what happened to the email thread for me; it looks >> like >>>> one >>>>>> of >>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- >>>>>> runtime- >>>>>>>>>> dev, >>>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>>> >>>>>>>>>> I like the idea, just quibbling over details. I've only reviewed >>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the details >>>>>>>>>> are settled. >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>> 470 // Helper macros to workaround existing #defines that spoil >>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>>>>>> >>>>>>>>>> This issue can be dodged by making the leading underscore part >> of >>>> the >>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>> make/lib/CompileJvm.gmk, >>>>>> use >>>>>>>>>> instead >>>>>>>>>> >>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>>>> 68 - >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>> \ >>>>>>>>>> >>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>> >>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>> >>>>>>>>>> #define cpu_header_stem(basename) >> PASTE_TOKENS(basename, >>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>> #define os_cpu_header_stem(basename) >>>> PASTE_TOKENS(basename, >>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>>>>>> >>>>>>>>>> #define cpu_header(basename) >>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>> #define os_header(basename) >>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>> >>>>>>>>>> And SUB is no longer used... >>>>>>>>>> >>>>>>>>>> If some future build system wants brackets instead of strings, just >>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>> >>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but that's >> true >>>>>>>>>> for the webrev.01 code too. But note that underscore followed >> by a >>>>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>>>>>> >>>>>>>>>> BTW, my preference would be to use uppercase for the macro >>>> names. >>>>>> I >>>>>>>>>> don't know what others think about that. >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> From harold.seigel at oracle.com Mon Jul 18 18:00:30 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 18 Jul 2016 14:00:30 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: Hi Alan, The JVM does not look for the -m (or --module) option. Instead, it checks if property "jdk.module.main" is non-null. If it is non-null then the JVM uses the option name in its "Cannot use the following option when dumping the shared archive" message, as in: > $JAVA_TEST/bin/java -Xshare:dump -m my_mod Error occurred during initialization of VM Cannot use the following option when dumping the shared archive: -m Unfortunately, it prints "-m" regardless of whether -m or --module was specified. Harold On 7/18/2016 3:13 AM, Alan Bateman wrote: > On 18/07/2016 00:05, harold seigel wrote: > >> Hi, >> >> Please review these Hotspot VM only changes to process the seven >> module-specific options that have been renamed to have gnu-like >> names. JDK changes for this bug will be reviewed separately. >> >> Descriptions of these options are here >> . For these six options, >> --module-path, --upgrade-module-path, --add-modules, --limit-modules, >> --add-reads, and --add-exports, the JVM just sets a system property. >> For the --patch-module option, the JVM sets a system property and >> then processes the option in the same way as when it was named -Xpatch. >> >> Additionally, the JVM now checks properties specified on the command >> line. If a property matches one of the properties used by one of the >> above options then the JVM ignores the property. This forces users to >> use the explicit option when wanting to do things like add a module >> or a package export. >> >> The RFR contains two new tests. Also, many existing tests were >> changed to use the new option names. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ > A passing comment on unsupported_options (options not allowed when > using -Xshare:dump) then it has -m in the list. I assume that should > not be there. That is java launcher option, the VM don't see or > unrecognize it, also it's long form is --module. > > -Alan From max.ockner at oracle.com Mon Jul 18 18:28:08 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 18 Jul 2016 14:28:08 -0400 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> Message-ID: <578D1FB8.9060601@oracle.com> Hi Marcus, Looks good. Thanks, Max On 7/18/2016 4:49 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add unit tests for the unified > logging framework. Tests are written for the new gtest unit test > framework. Most of the public functions for UL should be covered, but > later additions have internal vm tests (in log.cpp) that will be > ported separately. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8061219 > > Testing: > New tests through JPRT > > Thanks, > Marcus From jiangli.zhou at Oracle.COM Mon Jul 18 18:58:04 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Mon, 18 Jul 2016 11:58:04 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <578975C8.8000807@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> <57894C2B.8050308@oracle.com> <2BC2F0E3-C753-4F3B-BAA8-B802179DA1CA@oracle.com> <578975C8.8000807@oracle.com> Message-ID: <62F98AAF-A6A7-406C-818A-9FEC9A388BE6@oracle.com> Hi Serguei and Ioi, Here is updated webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.02/. I filed JDK-8161605 for JvmtiManageCapabilities::recompute_always_capabilities issue. Thanks, Jiangli > On Jul 15, 2016, at 4:46 PM, serguei.spitsyn at oracle.com wrote: > > On 7/15/16 14:51, Jiangli Zhou wrote: >> Hi Serguei, >> >> Thank you for the comments. >> >>> On Jul 15, 2016, at 1:48 PM, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Jiangli, >>> >>> It looks good in general. >>> >>> Some minor comments. >>> /src/share/vm/memory/metaspaceShared.cpp >>> >>> 1239 void MetaspaceShared::check_sharing_for_post_class_file_load_hook() { >>> 1240 if (JvmtiExport::should_post_class_file_load_hook() && UseSharedSpaces) { >>> 1241 // If RequireSharedSpaces is true, report error and exit. >>> 1242 if (RequireSharedSpaces) { >>> 1243 tty->print_cr("An error has occurred while loading shared class."); >>> 1244 tty->print_cr("Tool agent requires sharing to be disabled."); >>> 1245 vm_exit(1); >>> 1246 } >>> It seems, the printed log at L1243-1244 is out of context. There is no loading of a shared class as this function is called during the initialization. src/share/vm/memory/metaspaceShared.hpp >> Agreed. The message is out of context. >> Ioi suggested to remove the above check. That would results different behaviors for agents started from command-line running with -Xshare:on. In some cases the VM terminates, in other cases it continues but not loading from shared archive. Since the goal for this bug fix is backwards compatibility with 8 and it is a temporary solution, I agree with Ioi and will remove above function. > I had similar thoughts and agree with this approach. >> >>> + //Check sharing and JvmtiExport::should_post_class_file_load_hook requirement. >>> Please, add a space after the "//". There is still a question about what to do with this code in the jvmtiManageCapabilities.cpp: >> Same as above. Will remove the comment. > Ok. >> >>> // if the capability sets are initialized in the onload phase then >>> // it happens before class data sharing (CDS) is initialized. If it >>> // turns out that CDS gets disabled then we must adjust the always >>> // capabilities. To ensure a consistent view of the capabililties >>> // anything we add here should already be in the onload set. >>> void JvmtiManageCapabilities::recompute_always_capabilities() { >>> if (!UseSharedSpaces) { >>> jvmtiCapabilities jc = always_capabilities; >>> jc.can_generate_all_class_hook_events = 1; >>> always_capabilities = jc; >>> } >>> } >>> Should we make it unconditional and independent from the UseSharedSpaces flag? >> I agree, the UseSharedSpaces check does not seem to be needed here. > Good. >> >> Looking at related code, looks like can_generate_all_class_hook_events is set to 1 by JvmtiManageCapabilities::init_onload_capabilities(). So it is always enabled already. > The onload_capabilities and always capabilities are different. But I'm not sure why they need to be differentiated. In fact, this code is tricky and hard to understand. >> >> I wonder what the special handling of can_generate_all_class_hook_events is needed here then. Do you have any insight? > Honestly, I'm not sure yet. An accurate analysis is needed to get to a conclusion. >> >> I?ll file a separate bug for removing the UseSharedSpaces check from recompute_always_capabilities(). > Ok, thanks. Thanks, Serguei >> >> Thanks, >> Jiangli >>> Thanks, Serguei On 7/13/16 17:06, Jiangli Zhou wrote: >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~jiangli/8141341/webrev.01/ >>>> >>>> Following is the summary of the VM behavior under difference conditions. Since this is to temporary disable sharing for CFLH, I choose to use the solution that?s least disruptive (hopefully). >>>> Agent specified via command line: >>>> With -Xshare:on, report error and exit. >>>> Checks are added in Meatspace::global_initialize() and Threads::create_vm(). The check in Meatspace::global_initialize() detects early enabling of JvmtiExport::should_post_class_file_load_hook(). The check added in Threads::create_vm() is to detect the enabling of JvmtiExport::should_post_class_file_load_hook() later during the VM initialization. >>>> With -Xshare:auto, disallow loading shared class >>>> If JvmtiExport::should_post_class_file_load_hook() is enabled before mapping shared archive and initialize_preloaded_classes() (init_globals()), disable sharing entirely. That is ensured by the check added in Meatspace::global_initialize(). >>>> If JvmtiExport::should_post_class_file_load_hook() is enabled after init_globals(), the String class is loaded from the shared archive, only disallow loading shared class but shared Strings can still be used. Ensured by checks added in load_shared_class(). >>>> Agent is attached: >>>> With -Xshare:on and -Xshare:auto >>>> Disallow loading shared class after JvmtiExport::should_post_class_file_load_hook() is enabled. Shared Strings can still be used because the String class is already loaded from the shared archive during VM initialization. >>>> Karen, I moved cds_address into the ?if (UseSharedSpaces)? as you suggested. There are code after the >>>> 'if (UseSharedSpaces)? that should be executed as part of the ?else? case of ?if (DumpSharedSpaces)?. So left the #if INCLUDE_CDS unchanged for ?if (DumpSharedSpaces)?. >>>> >>>> Serguei, I added ?delete mapinfo? after FileMapInfo::fail_continue. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> >>>> >>>>> On Jul 8, 2016, at 6:14 PM, Jiangli Zhou wrote: >>>>> >>>>> Hi Ioi, >>>>> >>>>>> On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> I agree what what Karen has said. >>>>>> >>>>>> If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. >>>>>> >>>>>> We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. >>>>> Agreed. >>>>> >>>>>> Also, maybe this check can also be removed? >>>>>> >>>>>> 1247 instanceKlassHandle SystemDictionary::load_shared_class( >>>>>> 1248 Symbol* class_name, Handle class_loader, TRAPS) { >>>>>> 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< >>>>>> >>>>>> Since the same check is already done in the "inner" load_shared_class() method. >>>>> I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> >>>>>> On 7/8/16 11:18 AM, Jiangli Zhou wrote: >>>>>>> Hi Karen, >>>>>>> >>>>>>> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>>>>>>> >>>>>>>> Jiangli, >>>>>>>> >>>>>>>> Thank you so much for picking up this bug fix, I very much appreciate that. >>>>>>>> >>>>>>>> I agree with not quitting the vm on agent attach. >>>>>>>> I actually think we also want the agent attach to succeed - see below. >>>>>>>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>>>>>>> >>>>>>>>> (Adding serviceability-dev at openjdk.java.net ) >>>>>>>>> >>>>>>>>> Hi Jiangli, >>>>>>>>> >>>>>>>>> I think the two blocks of >>>>>>>>> >>>>>>>>> if (RequireSharedSpaces) { >>>>>>>>> tty->print_cr("An error has occurred while loading shared class."); >>>>>>>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>>>>>>> vm_exit(1); >>>>>>>>> } >>>>>>>>> >>>>>>>>> should be removed. >>>>>>>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>>>>>>> but no forcing of using the shared spaces if there is an agent. >>>>>>>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>>>>>>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>>>>>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>>>>>>> Totally agree - we should not quit the VM. >>>>>>>> >>>>>>>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>>>>>>> >>>>>>>>> jvmtiError >>>>>>>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>>>>>>> >>>>>>>>> ... >>>>>>>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>>>>>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>>>>>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>>>>>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>>>>>>> + } >>>>>>>>> record_class_file_load_hook_enabled(); >>>>>>>>> } >>>>>>>>> ? >>>>>>>>> } >>>>>>>>> >>>>>>>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>>>>>>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>>>>>>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>>>>>>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>>>>>>> Thanks >>>>>>>>> - Ioi >>>>>>>> Jiangli: >>>>>>>> >>>>>>>> Minor code review comments: >>>>>>>> >>>>>>>> metaspace.cpp line 3181: CFHL-> CFLH >>>>>>>> >>>>>>>> metaspace.cpp: >>>>>>>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>>>>>>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>>>>>>> use locally, so it also could be inside the #if INCLUDE_CDS. >>>>>>>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>>>>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>>>>>>> bug: JDK-8141341 >>>>>>>>>> >>>>>>>>>> With -Xshare:on >>>>>>>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>>>>>>> >>>>>>>>>> With -Xshare:auto >>>>>>>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>>>>>>> >>>>>>>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jiangli >>>>>>>>>> >>>>>>>>>> From rachel.protacio at oracle.com Mon Jul 18 19:39:26 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 18 Jul 2016 15:39:26 -0400 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> Message-ID: <95c286d5-4049-c49b-9d5d-7e45fcfaff9a@oracle.com> Looks good to me too. Rachel On 7/18/2016 4:49 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add unit tests for the unified > logging framework. Tests are written for the new gtest unit test > framework. Most of the public functions for UL should be covered, but > later additions have internal vm tests (in log.cpp) that will be > ported separately. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8061219 > > Testing: > New tests through JPRT > > Thanks, > Marcus From chris.plummer at oracle.com Mon Jul 18 20:41:47 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Jul 2016 13:41:47 -0700 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED In-Reply-To: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> References: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> Message-ID: <2beec655-c945-4567-47f7-167cec25fd39@oracle.com> Hi David, webrev.hotspot/src/cpu/x86/vm/globalDefinitions_x86.hpp: I'm curious as to why the JAVASE_EMBEDDED reference was ever there, but your fix seems correct. webrev.jdk/make/lib/Awt2dLibraries.gmk: I know this is really for the JDK review thread, but I'm not on it so I'll just ask here. Any reason you didn't just remove the BUILD_LIBAWT_XAWT_XToolkit.c_CFLAGS code instead of commenting it out as you did? thanks, Chris On 7/13/16 9:26 PM, David Holmes wrote: > The bug report for this is confidential but quite simply all of the > little tweaks and knobs we added to the open build and source files to > support the Java SE Embedded product no longer need to be there for > JDK 9. A lot of this has already been addressed in relation to other > changes (eg. new hotspot build), but this cleans out the rest. > > webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ > > There are related JDK changes being handled in a separate review > thread. If you like you can see them all: > > http://cr.openjdk.java.net/~dholmes/8140723/ > > Thanks, > David From coleen.phillimore at oracle.com Mon Jul 18 23:38:18 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Jul 2016 19:38:18 -0400 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/src/cpu/aarch64/vm/vm_version_aarch64.cpp.udiff.html -#ifdef TARGET_OS_FAMILY_linux -# include "os_linux.inline.hpp" -#endif + +#include OS_HEADER(os) Why isn't this OS_HEADER_INLINE (if there's such a macro), since it's including the .inline.hpp file? Why is there just this single #include os_linux.inline.hpp and not the cascade of os_aix.hpp files? For the record, the original intent on having these cascading #include directives and not having dispatch .hpp files (ala creating an "os_cpu.hpp" file for example) was so that eventually all the #include directives would be pushed down to the lowest level that needed it, and everything would be super-local and clean :) For example, the only cpp files that needed anything in assembler_x86.hpp would be already located in the src/cpu/x86/vm directory and could include assembler_x86.hpp directly. I still think this is a worthwhile goal but from reading this, the sources are far from this. I also didn't want us to have to create empty platform files (but I see some were added here). Maybe macroAssembler_cpu.inline.hpp inclusion can be pushed down after this change as a further cleanup. This looks great though, and sorely needed, especially when adding a new platform or cpu implementation. Thanks, Coleen On 7/15/16 8:17 AM, Lindenmaier, Goetz wrote: > Hi, > > I made a new webrev: > - '_' is added in makefile > - uses Kim's macros > - macros are capitalized > - more comments in macros.hpp > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ > > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 15. Juli 2016 11:11 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>> HI Kim, >>> >>> thanks for this version of the macros, it's working on all the platforms >>> I can build. >>> >>> Actually, I would prefer having the '_' in the macros and not on the >>> command line. This way, parts of the name construction are in >>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>> the search path is also in the makefile, and uses the very same string >>> as the file suffixes. (Without '_', one could include that in the macro, too.) >>> >>> But overall, I consider this a detail and am as fine with your solution >>> as with the SUB() macros. What is better is that the linux=1 etc >>> problems are avoided. >>> >>> Any more opinions whether the macros should be upper case? >> Yeah they probably should be. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>> To: Lindenmaier, Goetz >>>> Cc: Andrew Haley ; hotspot-compiler- >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>> wrote: >>>>> Hi everybody, >>>>> >>>>> please take into account that these macros are only used within 20 lines >> of >>>>> the file macro.hpp. The code everybody needs to understand is >>>>> #include cpu_header(bytes) >>>>> which, in this example, is in file bytes.hpp and expands to >>>> bytes_.hpp. >>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>> >>>>> I really would appreciate if I don't have to spend days editing the >>>>> 12 lines that use SUB(). >>>>> >>>>> @Kim >>>>> I'm working on the s390 port, and posted my current progress claiming >>>>> that the biggest shared change I need to do is adding the #includes. >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>> July/023782.html >>>>> This arose the discussion about the includes. >>>>> Later I posted a prototype of what Volker proposed in that discussion >>>>> to that thread: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>> July/023934.html >>>>> which I now turned into a RFR. >>>> Thanks. >>>> >>>> I think I see what happened to the email thread for me; it looks like one of >>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot-runtime- >>>> dev, >>>> and I was not subscribed to the compiler list this morning. >>>> >>>> I like the idea, just quibbling over details. I've only reviewed >>>> macros.hpp so far; the rest looks like it can wait until the details >>>> are settled. >>>> >>>> ------------------------------------------------------------------------------ >>>> src/share/vm/utilities/macros.hpp >>>> 470 // Helper macros to workaround existing #defines that spoil >>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>> >>>> This issue can be dodged by making the leading underscore part of the >>>> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, use >>>> instead >>>> >>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ >>>> >>>> Note the insertion of leading "_" for the values. >>>> >>>> Then the whole macro block can be written as >>>> >>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, >>>> INCLUDE_SUFFIX_CPU) >>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>> INCLUDE_SUFFIX_OS) >>>> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, >>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>> >>>> #define cpu_header(basename) >> XSTR(cpu_header_stem(basename).hpp) >>>> #define cpu_header_inline(basename) >>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>> #define os_header(basename) XSTR(os_header_stem(basename).hpp) >>>> #define os_header_inline(basename) >>>> XSTR(os_header_stem(basename).inline.hpp) >>>> #define os_cpu_header(basename) >>>> XSTR(os_cpu_header_stem(basename).hpp) >>>> #define os_cpu_header_inline(basename) >>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>> >>>> And SUB is no longer used... >>>> >>>> If some future build system wants brackets instead of strings, just >>>> replace XSTR(...) with <...>. >>>> >>>> We lose if _linux or _sparc (for example) are defined, but that's true >>>> for the webrev.01 code too. But note that underscore followed by a >>>> lowercase letter is not in the reserved word pattern for C/C++. >>>> >>>> BTW, my preference would be to use uppercase for the macro names. I >>>> don't know what others think about that. >>>> >>>> ------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Jul 19 00:09:25 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jul 2016 10:09:25 +1000 Subject: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED In-Reply-To: <2beec655-c945-4567-47f7-167cec25fd39@oracle.com> References: <51489c60-5736-2ce9-b84e-2964e9ee6546@oracle.com> <2beec655-c945-4567-47f7-167cec25fd39@oracle.com> Message-ID: <6dcaef84-57cb-56ab-0bf1-8b55d163ab6b@oracle.com> Hi Chris, Thanks for the review. On 19/07/2016 6:41 AM, Chris Plummer wrote: > Hi David, > > webrev.hotspot/src/cpu/x86/vm/globalDefinitions_x86.hpp: > > I'm curious as to why the JAVASE_EMBEDDED reference was ever there, but > your fix seems correct. It was done in 8077618. Can't recall exact reasoning. > > webrev.jdk/make/lib/Awt2dLibraries.gmk: > > I know this is really for the JDK review thread, but I'm not on it so > I'll just ask here. Any reason you didn't just remove the > BUILD_LIBAWT_XAWT_XToolkit.c_CFLAGS code instead of commenting it out as > you did? It will be deleted if the AWT team agree. I called that out explicitly on the JDK/AWT review thread. Thanks, David > thanks, > > Chris > > On 7/13/16 9:26 PM, David Holmes wrote: >> The bug report for this is confidential but quite simply all of the >> little tweaks and knobs we added to the open build and source files to >> support the Java SE Embedded product no longer need to be there for >> JDK 9. A lot of this has already been addressed in relation to other >> changes (eg. new hotspot build), but this cleans out the rest. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8140723/webrev.hotspot/ >> >> There are related JDK changes being handled in a separate review >> thread. If you like you can see them all: >> >> http://cr.openjdk.java.net/~dholmes/8140723/ >> >> Thanks, >> David > > From david.holmes at oracle.com Tue Jul 19 01:37:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jul 2016 11:37:27 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Message-ID: Hi Goetz, On 18/07/2016 10:23 PM, David Holmes wrote: > On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I'll introduce CPU_HEADER_H, but actually this should be fixed >> in the closed code. > > Bear with me, I'm trying to figure out how to do just that. :) > > The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef is not > going to work for our closed ports, unless I change that value to match > the open naming scheme. But that in turn will lead to other problems as > we also need that value the way it is currently defined. > > I'll tackle this again in the morning when I'm fresher. Sorry but this really does need the CPU_HEADER_H macro. In general you can't just replace: #ifdef TARGET_ARCH_abc with #ifdef abc because the "abc"'s may not be mutually exclusive. In our case ARM and AARCH64 are both defined and are both needed. In contrast TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent the architecture in this context. Thanks, David > Thanks, > David > > >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Montag, 18. Juli 2016 14:13 >>> To: Lindenmaier, Goetz ; Kim Barrett >>> >>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>> >>> Hi Goetz, >>> >>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>>>>> src/share/vm/prims/jni_md.h >>>>>>> src/share/vm/prims/jvm.h >>>>>>> >>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>> >>>>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>>>> instead? >>>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>>> So I figured not to do it. But probably I should do it to get is >>>>>> similar everywhere. >>>>> >>>>> We actually need this as the simple arch names need not be mutually >>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>>> construct in the correct order. ;-) >>>> They should be mutually exclusive, as they are set in CompileJvm.gmk >>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>> >>> Unfortunately we also have -DARM coming in from the closed part of >>> spec.gmk as we don't use AARCH64 for our port. So we get both defined >>> and try to include two platform files. >>> >>> Not sure how to try and resolve this yet. Trying to understand what the >>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not >>> overriding it for our port - which I think is the current problem, but >>> changing it may break something else. >>> >>> Thanks, >>> David >>> >>> >>>> Best regards, >>>> Goetz >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>> >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>> >>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> thanks for looking at all these files in more detail! >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>> >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> Again thanks for tackling this! >>>>>>> >>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I made a new webrev: >>>>>>>> - '_' is added in makefile >>>>>>>> - uses Kim's macros >>>>>>>> - macros are capitalized >>>>>>>> - more comments in macros.hpp >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>> newPfmIncl/webrev.02/ >>>>>>> >>>>>>> Generally looks okay, a couple of clarifications and comments below. >>>>>>> >>>>>>> >>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>> >>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>> affects the generated files right? >>>>>> Yes. >>>>>>> For our closed ports we still have >>>>>>> the _32/_64 source files in a common arch directory, but I don't >>>>>>> think >>>>>>> that needs to be reflected in the generated files. (Sorry I >>>>>>> haven't had >>>>>>> the time yet to apply this patch and see what needs to be changed on >>> the >>>>>>> closed side - but will start that once I send this :).) >>>>>> If I run plain configure, it generates a directory that has the >>>>>> word size >>>>>> in it's name: >>>>>> linux-x86_64-normal-server-release >>>>>> If I configure --with-target-bits=32, it builds to >>>>>> linux-x86-normal-server-release, >>>>>> so I figured this should be fine. >>>>> >>>>> Yes generated files are fine. >>>>> >>>>>>> make/lib/CompileJvm.gmk >>>>>>> >>>>>>> Hmm but this change assumes no more _32/_64 header files if I >>>>>>> read it >>>>>>> right ?? So I'll need a common file that dispatches internally for >>>>>>> 32-bit and 64-bit. >>>>>> Yes. >>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>> stubRoutines >>>>>> But this was rather small. And there anyways was a common file >>>>>> that was included in both. >>>>>> >>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>> >>>>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>>>> switch(OS) statement: >>>>>>> >>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>> ... >>>>>>> >>>>>>> ie something like: >>>>>>> >>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>> >>>>>>> ? :) >>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>> Actually I think the implementation should be moved to >>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/share/vm/code/nmethod.cpp >>>>>>> >>>>>>> Not clear why the platform include can simply be elided here ?? >>>>>> It already includes code/nativeInst.hpp, which is the umbrella header >>>>>> for all the platform files. >>>>>> >>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>> >>>>>>> Shouldn't: >>>>>>> >>>>>>> ! #endif // !LP64 >>>>>>> >>>>>>> be: >>>>>>> >>>>>>> ! #endif // LP64 >>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/share/vm/prims/jni_md.h >>>>>>> src/share/vm/prims/jvm.h >>>>>>> >>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>> >>>>>>> can we not define a second form, eg CPU_HEADER_H, that appends.h >>>>>>> instead? >>>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>>> So I figured not to do it. But probably I should do it to get is >>>>>> similar everywhere. >>>>> >>>>> We actually need this as the simple arch names need not be mutually >>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>>> construct in the correct order. ;-) >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/share/vm/runtime/os.hpp >>>>>>> >>>>>>> Should we convert setjmp.h include to: >>>>>>> >>>>>>> #ifndef _WINDOWS >>>>>>> #include >>>>>>> #endif >>>>>>> #ifdef __APPLE__ >>>>>>> ... >>>>>>> #endif >>>>>>> ? >>>>>> Fixed. >>>>>> >>>>>> >>>>>>> >>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming from >>> the >>>>>>> compiler itself? >>>>>> I wondered about that, too. Therefore I defined WINDOWS in the >>>>>> prototype webrev. Then I saw that our build is defining -D_WINDOWS >>>>> *and* -DWIN32, >>>>>> and removed it again using _WINDOWS instead. >>>>>> Eventually both should be replaced by WINDOWS, but not in this >>>>>> change. >>>>>> >>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>> >>>>>>> Don't understand the point of this: >>>>>>> >>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>> 29 // Aix is not littel endian. >>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>> >>>>>>> also typo: littel >>>>>> I just copied the linux_ppc code and removed the unused >>> implementation. >>>>>> I wanted to document why there is this empty file. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>> >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> HI Kim, >>>>>>>>>> >>>>>>>>>> thanks for this version of the macros, it's working on all the >>> platforms >>>>>>>>>> I can build. >>>>>>>>>> >>>>>>>>>> Actually, I would prefer having the '_' in the macros and not >>>>>>>>>> on the >>>>>>>>>> command line. This way, parts of the name construction are in >>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But constructing >>>>>>>>>> the search path is also in the makefile, and uses the very same >>> string >>>>>>>>>> as the file suffixes. (Without '_', one could include that in the >>> macro, >>>>>>> too.) >>>>>>>>>> >>>>>>>>>> But overall, I consider this a detail and am as fine with your >>>>>>>>>> solution >>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>>>>>>> problems are avoided. >>>>>>>>>> >>>>>>>>>> Any more opinions whether the macros should be upper case? >>>>>>>>> >>>>>>>>> Yeah they probably should be. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>> >>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi everybody, >>>>>>>>>>>> >>>>>>>>>>>> please take into account that these macros are only used within >>> 20 >>>>>>> lines >>>>>>>>> of >>>>>>>>>>>> the file macro.hpp. The code everybody needs to understand is >>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>>>>>>> >>>>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>>>> editing the >>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>> >>>>>>>>>>>> @Kim >>>>>>>>>>>> I'm working on the s390 port, and posted my current progress >>>>> claiming >>>>>>>>>>>> that the biggest shared change I need to do is adding the >>> #includes. >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>>> July/023782.html >>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>> Later I posted a prototype of what Volker proposed in that >>>>> discussion >>>>>>>>>>>> to that thread: >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>>> July/023934.html >>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> I think I see what happened to the email thread for me; it looks >>> like >>>>> one >>>>>>> of >>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- >>>>>>> runtime- >>>>>>>>>>> dev, >>>>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>>>> >>>>>>>>>>> I like the idea, just quibbling over details. I've only >>>>>>>>>>> reviewed >>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the >>>>>>>>>>> details >>>>>>>>>>> are settled. >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>> 470 // Helper macros to workaround existing #defines that spoil >>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>>>>>>> >>>>>>>>>>> This issue can be dodged by making the leading underscore part >>> of >>>>> the >>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>> make/lib/CompileJvm.gmk, >>>>>>> use >>>>>>>>>>> instead >>>>>>>>>>> >>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>>>>> 68 - >>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>> \ >>>>>>>>>>> >>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>> >>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>> >>>>>>>>>>> #define cpu_header_stem(basename) >>> PASTE_TOKENS(basename, >>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>> #define os_header_stem(basename) PASTE_TOKENS(basename, >>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>> PASTE_TOKENS(basename, >>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>>>>>>> >>>>>>>>>>> #define cpu_header(basename) >>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>> #define os_header(basename) >>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>> >>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>> >>>>>>>>>>> If some future build system wants brackets instead of >>>>>>>>>>> strings, just >>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>> >>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but >>>>>>>>>>> that's >>> true >>>>>>>>>>> for the webrev.01 code too. But note that underscore followed >>> by a >>>>>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>>>>>>> >>>>>>>>>>> BTW, my preference would be to use uppercase for the macro >>>>> names. >>>>>>> I >>>>>>>>>>> don't know what others think about that. >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> From goetz.lindenmaier at sap.com Tue Jul 19 05:58:51 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Jul 2016 05:58:51 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <578754C6.50806@redhat.com> <57876129.8000303@redhat.com> <866f27992066403482fc646545564ad8@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> Message-ID: <4cb3929b36ce49ffb8acf17ef2ddec16@DEWDFE13DE09.global.corp.sap> Hi Coleen, thanks for looking at this. > http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.02/src/cpu/aarch64/vm/vm_version_aarch64.cpp.udiff. > html > +#include OS_HEADER(os) > Why isn't this OS_HEADER_INLINE (if there's such a macro), since it's > including the .inline.hpp file? Good catch, fixed. > Why is there just this single #include os_linux.inline.hpp and not the > cascade of os_aix.hpp files? Which file do you mean? > For the record, the original intent on having these cascading #include > directives and not having dispatch .hpp files (ala creating an > "os_cpu.hpp" file for example) was so that eventually all the #include > directives would be pushed down to the lowest level that needed it, and > everything would be super-local and clean :) For example, the only cpp > files that needed anything in assembler_x86.hpp would be already located > in the src/cpu/x86/vm directory and could include assembler_x86.hpp > directly. I still think this is a worthwhile goal but from reading > this, the sources are far from this. This might be nice, but the platform files often implement a inline method called in shared code, so the shared code must include them. For the macroAssembler example: macroAssembler_sparc.inline.hpp defines MacroAssembler::bang_stack_with_offset(int offset) which is called in assembler.cpp. Probably this can be cleaned up for the assembler files (I don't think inlining this method has any performance effects, and other similar cases should not either), but it won't be possible for all. Especially the atomic headers from the os_cpu directories are needed as inline functions. But with the new macros pure umbrella headers could be removed. I still find them quite useful. > I also didn't want us to have to create empty platform files (but I see > some were added here). Maybe macroAssembler_cpu.inline.hpp inclusion > can be pushed down after this change as a further cleanup. Actually, I'm removing more empty files than I add :). But it's a fact that these macros require them, except if I surround them by #ifndef X86 (for this case). > This looks great though, and sorely needed, especially when adding a new > platform or cpu implementation. Yes, we should have had this before the ppc port, would have saved work for us and aarch :) But it really simplifies porting! Best regards, Goetz. > > Thanks, > Coleen > > On 7/15/16 8:17 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I made a new webrev: > > - '_' is added in makefile > > - uses Kim's macros > > - macros are capitalized > > - more comments in macros.hpp > > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.02/ > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 15. Juli 2016 11:11 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>> HI Kim, > >>> > >>> thanks for this version of the macros, it's working on all the platforms > >>> I can build. > >>> > >>> Actually, I would prefer having the '_' in the macros and not on the > >>> command line. This way, parts of the name construction are in > >>> CompileJvm.gmk, other parts are in macros.hpp. But constructing > >>> the search path is also in the makefile, and uses the very same string > >>> as the file suffixes. (Without '_', one could include that in the macro, > too.) > >>> > >>> But overall, I consider this a detail and am as fine with your solution > >>> as with the SUB() macros. What is better is that the linux=1 etc > >>> problems are avoided. > >>> > >>> Any more opinions whether the macros should be upper case? > >> Yeah they probably should be. > >> > >> Thanks, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>> To: Lindenmaier, Goetz > >>>> Cc: Andrew Haley ; hotspot-compiler- > >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>> wrote: > >>>>> Hi everybody, > >>>>> > >>>>> please take into account that these macros are only used within 20 > lines > >> of > >>>>> the file macro.hpp. The code everybody needs to understand is > >>>>> #include cpu_header(bytes) > >>>>> which, in this example, is in file bytes.hpp and expands to > >>>> bytes_.hpp. > >>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > >>>>> > >>>>> I really would appreciate if I don't have to spend days editing the > >>>>> 12 lines that use SUB(). > >>>>> > >>>>> @Kim > >>>>> I'm working on the s390 port, and posted my current progress > claiming > >>>>> that the biggest shared change I need to do is adding the #includes. > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>> July/023782.html > >>>>> This arose the discussion about the includes. > >>>>> Later I posted a prototype of what Volker proposed in that discussion > >>>>> to that thread: > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>> July/023934.html > >>>>> which I now turned into a RFR. > >>>> Thanks. > >>>> > >>>> I think I see what happened to the email thread for me; it looks like one > of > >>>> Andrew?s replies went to hotspot-compiler-dev but not hotspot- > runtime- > >>>> dev, > >>>> and I was not subscribed to the compiler list this morning. > >>>> > >>>> I like the idea, just quibbling over details. I've only reviewed > >>>> macros.hpp so far; the rest looks like it can wait until the details > >>>> are settled. > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> src/share/vm/utilities/macros.hpp > >>>> 470 // Helper macros to workaround existing #defines that spoil > >>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. > >>>> > >>>> This issue can be dodged by making the leading underscore part of the > >>>> expansion for INCLUDE_SUFFIX_*, e.g. in make/lib/CompileJvm.gmk, > use > >>>> instead > >>>> > >>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >>>> 68 -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) \ > >>>> > >>>> Note the insertion of leading "_" for the values. > >>>> > >>>> Then the whole macro block can be written as > >>>> > >>>> #define cpu_header_stem(basename) PASTE_TOKENS(basename, > >>>> INCLUDE_SUFFIX_CPU) > >>>> #define os_header_stem(basename) PASTE_TOKENS(basename, > >>>> INCLUDE_SUFFIX_OS) > >>>> #define os_cpu_header_stem(basename) PASTE_TOKENS(basename, > >>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > >>>> > >>>> #define cpu_header(basename) > >> XSTR(cpu_header_stem(basename).hpp) > >>>> #define cpu_header_inline(basename) > >>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>> #define os_header(basename) XSTR(os_header_stem(basename).hpp) > >>>> #define os_header_inline(basename) > >>>> XSTR(os_header_stem(basename).inline.hpp) > >>>> #define os_cpu_header(basename) > >>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>> #define os_cpu_header_inline(basename) > >>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>> > >>>> And SUB is no longer used... > >>>> > >>>> If some future build system wants brackets instead of strings, just > >>>> replace XSTR(...) with <...>. > >>>> > >>>> We lose if _linux or _sparc (for example) are defined, but that's true > >>>> for the webrev.01 code too. But note that underscore followed by a > >>>> lowercase letter is not in the reserved word pattern for C/C++. > >>>> > >>>> BTW, my preference would be to use uppercase for the macro names. > I > >>>> don't know what others think about that. > >>>> > >>>> ------------------------------------------------------------------------------ From goetz.lindenmaier at sap.com Tue Jul 19 07:47:32 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Jul 2016 07:47:32 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <57877A72.5050405@redhat.com> <4c2267d140a545b19bafe544659ab0fb@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> Message-ID: <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> Hi, I added macros for C headers: CPU_HEADER_H() etc. and fixed the other issues mentioned by David and Coleen in this new webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.03/ I also added comments that AARCH64 and ARM are defined at the same time. Further I edited vmStructs_jvmci.cpp to #if defined(AARCH64) && !defined(ARM) My incremental changes are in this patch: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.03/incremental_changes.patch Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, July 19, 2016 3:37 AM > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Hi Goetz, > > On 18/07/2016 10:23 PM, David Holmes wrote: > > On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >> Hi David, > >> > >> I'll introduce CPU_HEADER_H, but actually this should be fixed > >> in the closed code. > > > > Bear with me, I'm trying to figure out how to do just that. :) > > > > The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef is not > > going to work for our closed ports, unless I change that value to match > > the open naming scheme. But that in turn will lead to other problems as > > we also need that value the way it is currently defined. > > > > I'll tackle this again in the morning when I'm fresher. > > Sorry but this really does need the CPU_HEADER_H macro. In general you > can't just replace: > > #ifdef TARGET_ARCH_abc > > with > > #ifdef abc > > because the "abc"'s may not be mutually exclusive. In our case ARM and > AARCH64 are both defined and are both needed. In contrast > TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent the > architecture in this context. > > Thanks, > David > > > Thanks, > > David > > > > > >> Best regards, > >> Goetz. > >> > >> > >>> -----Original Message----- > >>> From: David Holmes [mailto:david.holmes at oracle.com] > >>> Sent: Montag, 18. Juli 2016 14:13 > >>> To: Lindenmaier, Goetz ; Kim Barrett > >>> > >>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>> > >>> Hi Goetz, > >>> > >>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>> Hi David, > >>>> > >>>>>>> src/share/vm/prims/jni_md.h > >>>>>>> src/share/vm/prims/jvm.h > >>>>>>> > >>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>> > >>>>>>> can we not define a second form, eg CPU_HEADER_H, that > appends.h > >>>>>>> instead? > >>>>>> I'll need one for OS, one for CPU, and each will be used only once. > >>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>> similar everywhere. > >>>>> > >>>>> We actually need this as the simple arch names need not be mutually > >>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else > >>>>> construct in the correct order. ;-) > >>>> They should be mutually exclusive, as they are set in CompileJvm.gmk > >>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>> > >>> Unfortunately we also have -DARM coming in from the closed part of > >>> spec.gmk as we don't use AARCH64 for our port. So we get both defined > >>> and try to include two platform files. > >>> > >>> Not sure how to try and resolve this yet. Trying to understand what the > >>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not > >>> overriding it for our port - which I think is the current problem, but > >>> changing it may break something else. > >>> > >>> Thanks, > >>> David > >>> > >>> > >>>> Best regards, > >>>> Goetz > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>> > >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>> > >>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>> Hi David, > >>>>>> > >>>>>> thanks for looking at all these files in more detail! > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>>> > >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>> dev at openjdk.java.net > >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>> > >>>>>>> Hi Goetz, > >>>>>>> > >>>>>>> Again thanks for tackling this! > >>>>>>> > >>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I made a new webrev: > >>>>>>>> - '_' is added in makefile > >>>>>>>> - uses Kim's macros > >>>>>>>> - macros are capitalized > >>>>>>>> - more comments in macros.hpp > >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>> newPfmIncl/webrev.02/ > >>>>>>> > >>>>>>> Generally looks okay, a couple of clarifications and comments > below. > >>>>>>> > >>>>>>> > >>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>> > >>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>> affects the generated files right? > >>>>>> Yes. > >>>>>>> For our closed ports we still have > >>>>>>> the _32/_64 source files in a common arch directory, but I don't > >>>>>>> think > >>>>>>> that needs to be reflected in the generated files. (Sorry I > >>>>>>> haven't had > >>>>>>> the time yet to apply this patch and see what needs to be changed > on > >>> the > >>>>>>> closed side - but will start that once I send this :).) > >>>>>> If I run plain configure, it generates a directory that has the > >>>>>> word size > >>>>>> in it's name: > >>>>>> linux-x86_64-normal-server-release > >>>>>> If I configure --with-target-bits=32, it builds to > >>>>>> linux-x86-normal-server-release, > >>>>>> so I figured this should be fine. > >>>>> > >>>>> Yes generated files are fine. > >>>>> > >>>>>>> make/lib/CompileJvm.gmk > >>>>>>> > >>>>>>> Hmm but this change assumes no more _32/_64 header files if I > >>>>>>> read it > >>>>>>> right ?? So I'll need a common file that dispatches internally for > >>>>>>> 32-bit and 64-bit. > >>>>>> Yes. > >>>>>> There is a single file in cpu/x86 where this did not hold: > >>>>>> stubRoutines > >>>>>> But this was rather small. And there anyways was a common file > >>>>>> that was included in both. > >>>>>> > >>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>> > >>>>>>> I'm wondering if we can use a similar trick to avoid this kind of > >>>>>>> switch(OS) statement: > >>>>>>> > >>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>> ... > >>>>>>> > >>>>>>> ie something like: > >>>>>>> > >>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>> > >>>>>>> ? :) > >>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>>>>> Actually I think the implementation should be moved to > >>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>> > >>>>>>> > >>>>>>> --- > >>>>>>> > >>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>> > >>>>>>> Not clear why the platform include can simply be elided here ?? > >>>>>> It already includes code/nativeInst.hpp, which is the umbrella header > >>>>>> for all the platform files. > >>>>>> > >>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>> > >>>>>>> Shouldn't: > >>>>>>> > >>>>>>> ! #endif // !LP64 > >>>>>>> > >>>>>>> be: > >>>>>>> > >>>>>>> ! #endif // LP64 > >>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>> > >>>>>>> > >>>>>>> --- > >>>>>>> > >>>>>>> src/share/vm/prims/jni_md.h > >>>>>>> src/share/vm/prims/jvm.h > >>>>>>> > >>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>> > >>>>>>> can we not define a second form, eg CPU_HEADER_H, that > appends.h > >>>>>>> instead? > >>>>>> I'll need one for OS, one for CPU, and each will be used only once. > >>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>> similar everywhere. > >>>>> > >>>>> We actually need this as the simple arch names need not be mutually > >>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else > >>>>> construct in the correct order. ;-) > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> ----- > >>>>> > >>>>>>> > >>>>>>> --- > >>>>>>> > >>>>>>> src/share/vm/runtime/os.hpp > >>>>>>> > >>>>>>> Should we convert setjmp.h include to: > >>>>>>> > >>>>>>> #ifndef _WINDOWS > >>>>>>> #include > >>>>>>> #endif > >>>>>>> #ifdef __APPLE__ > >>>>>>> ... > >>>>>>> #endif > >>>>>>> ? > >>>>>> Fixed. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming > from > >>> the > >>>>>>> compiler itself? > >>>>>> I wondered about that, too. Therefore I defined WINDOWS in the > >>>>>> prototype webrev. Then I saw that our build is defining - > D_WINDOWS > >>>>> *and* -DWIN32, > >>>>>> and removed it again using _WINDOWS instead. > >>>>>> Eventually both should be replaced by WINDOWS, but not in this > >>>>>> change. > >>>>>> > >>>>>> > >>>>>>> --- > >>>>>>> > >>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>> > >>>>>>> Don't understand the point of this: > >>>>>>> > >>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>> 29 // Aix is not littel endian. > >>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>> > >>>>>>> also typo: littel > >>>>>> I just copied the linux_ppc code and removed the unused > >>> implementation. > >>>>>> I wanted to document why there is this empty file. > >>>>>> > >>>>>> Best regards, > >>>>>> Goetz. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> ----- > >>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Goetz. > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>> > >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>> dev at openjdk.java.net > >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>> > >>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> HI Kim, > >>>>>>>>>> > >>>>>>>>>> thanks for this version of the macros, it's working on all the > >>> platforms > >>>>>>>>>> I can build. > >>>>>>>>>> > >>>>>>>>>> Actually, I would prefer having the '_' in the macros and not > >>>>>>>>>> on the > >>>>>>>>>> command line. This way, parts of the name construction are in > >>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But > constructing > >>>>>>>>>> the search path is also in the makefile, and uses the very same > >>> string > >>>>>>>>>> as the file suffixes. (Without '_', one could include that in the > >>> macro, > >>>>>>> too.) > >>>>>>>>>> > >>>>>>>>>> But overall, I consider this a detail and am as fine with your > >>>>>>>>>> solution > >>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 etc > >>>>>>>>>> problems are avoided. > >>>>>>>>>> > >>>>>>>>>> Any more opinions whether the macros should be upper case? > >>>>>>>>> > >>>>>>>>> Yeah they probably should be. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- > >>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>> > >>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>> > >>>>>>>>>>>> please take into account that these macros are only used > within > >>> 20 > >>>>>>> lines > >>>>>>>>> of > >>>>>>>>>>>> the file macro.hpp. The code everybody needs to understand > is > >>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to > >>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. > >>>>>>>>>>>> > >>>>>>>>>>>> I really would appreciate if I don't have to spend days > >>>>>>>>>>>> editing the > >>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>> > >>>>>>>>>>>> @Kim > >>>>>>>>>>>> I'm working on the s390 port, and posted my current progress > >>>>> claiming > >>>>>>>>>>>> that the biggest shared change I need to do is adding the > >>> #includes. > >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>>>>>>> July/023782.html > >>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>> Later I posted a prototype of what Volker proposed in that > >>>>> discussion > >>>>>>>>>>>> to that thread: > >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>>>>>>> July/023934.html > >>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> > >>>>>>>>>>> I think I see what happened to the email thread for me; it looks > >>> like > >>>>> one > >>>>>>> of > >>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not > hotspot- > >>>>>>> runtime- > >>>>>>>>>>> dev, > >>>>>>>>>>> and I was not subscribed to the compiler list this morning. > >>>>>>>>>>> > >>>>>>>>>>> I like the idea, just quibbling over details. I've only > >>>>>>>>>>> reviewed > >>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the > >>>>>>>>>>> details > >>>>>>>>>>> are settled. > >>>>>>>>>>> > >>>>>>>>>>> ---------------------------------------------------------------------------- > -- > >>>>>>>>>>> > >>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>> 470 // Helper macros to workaround existing #defines that > spoil > >>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. > >>>>>>>>>>> > >>>>>>>>>>> This issue can be dodged by making the leading underscore > part > >>> of > >>>>> the > >>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>> make/lib/CompileJvm.gmk, > >>>>>>> use > >>>>>>>>>>> instead > >>>>>>>>>>> > >>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >>>>>>>>>>> 68 - > >>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>> \ > >>>>>>>>>>> > >>>>>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>>>>> > >>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>> > >>>>>>>>>>> #define cpu_header_stem(basename) > >>> PASTE_TOKENS(basename, > >>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>> #define os_header_stem(basename) > PASTE_TOKENS(basename, > >>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>> PASTE_TOKENS(basename, > >>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>> > >>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>> #define os_header(basename) > >>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>> > >>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>> > >>>>>>>>>>> If some future build system wants brackets instead of > >>>>>>>>>>> strings, just > >>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>> > >>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but > >>>>>>>>>>> that's > >>> true > >>>>>>>>>>> for the webrev.01 code too. But note that underscore > followed > >>> by a > >>>>>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. > >>>>>>>>>>> > >>>>>>>>>>> BTW, my preference would be to use uppercase for the macro > >>>>> names. > >>>>>>> I > >>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>> > >>>>>>>>>>> ---------------------------------------------------------------------------- > -- > >>>>>>>>>>> > >>>>>>>>>> From marcus.larsson at oracle.com Tue Jul 19 08:22:55 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Jul 2016 10:22:55 +0200 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: <578D1FB8.9060601@oracle.com> References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> <578D1FB8.9060601@oracle.com> Message-ID: Thanks for reviewing Max! Marcus On 07/18/2016 08:28 PM, Max Ockner wrote: > Hi Marcus, > Looks good. > Thanks, > Max > > On 7/18/2016 4:49 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add unit tests for the unified >> logging framework. Tests are written for the new gtest unit test >> framework. Most of the public functions for UL should be covered, but >> later additions have internal vm tests (in log.cpp) that will be >> ported separately. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8061219 >> >> Testing: >> New tests through JPRT >> >> Thanks, >> Marcus > From marcus.larsson at oracle.com Tue Jul 19 08:23:16 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Jul 2016 10:23:16 +0200 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: <95c286d5-4049-c49b-9d5d-7e45fcfaff9a@oracle.com> References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> <95c286d5-4049-c49b-9d5d-7e45fcfaff9a@oracle.com> Message-ID: <67c91885-5d5a-de47-b217-98e8f156d824@oracle.com> Thanks for reviewing Rachel! Marcus On 07/18/2016 09:39 PM, Rachel Protacio wrote: > Looks good to me too. > > Rachel > > > On 7/18/2016 4:49 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add unit tests for the unified >> logging framework. Tests are written for the new gtest unit test >> framework. Most of the public functions for UL should be covered, but >> later additions have internal vm tests (in log.cpp) that will be >> ported separately. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8061219 >> >> Testing: >> New tests through JPRT >> >> Thanks, >> Marcus > From marcus.larsson at oracle.com Tue Jul 19 08:25:15 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Jul 2016 10:25:15 +0200 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> Message-ID: <31036a63-bb39-6cf7-427d-00a42b3f1ab4@oracle.com> Still looking for a *R*eviewer for this. Thanks, Marcus On 07/18/2016 10:49 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add unit tests for the unified > logging framework. Tests are written for the new gtest unit test > framework. Most of the public functions for UL should be covered, but > later additions have internal vm tests (in log.cpp) that will be > ported separately. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8061219 > > Testing: > New tests through JPRT > > Thanks, > Marcus From david.holmes at oracle.com Tue Jul 19 08:46:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jul 2016 18:46:58 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> Message-ID: <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> Thanks Goetz. Will get back to you asap if there are any further issues, but the incremental changes look okay. On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > Hi, > > I added macros for C headers: > CPU_HEADER_H() etc. > and fixed the other issues mentioned by David and Coleen in this new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.03/ > > I also added comments that AARCH64 and ARM are defined > at the same time. > > Further I edited vmStructs_jvmci.cpp to > #if defined(AARCH64) && !defined(ARM) I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of workaround is obscure - you have to know that the Open Aarch64 port defines AARCH64 but not ARM and so that code is for the Open port use only. There's no issue for the OS defines, but I wonder - just something to thing about - if TARGET_ARCH_xxx should be restored? Thanks, David > My incremental changes are in this patch: > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.03/incremental_changes.patch > > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, July 19, 2016 3:37 AM >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> Hi Goetz, >> >> On 18/07/2016 10:23 PM, David Holmes wrote: >>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> I'll introduce CPU_HEADER_H, but actually this should be fixed >>>> in the closed code. >>> >>> Bear with me, I'm trying to figure out how to do just that. :) >>> >>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef is not >>> going to work for our closed ports, unless I change that value to match >>> the open naming scheme. But that in turn will lead to other problems as >>> we also need that value the way it is currently defined. >>> >>> I'll tackle this again in the morning when I'm fresher. >> >> Sorry but this really does need the CPU_HEADER_H macro. In general you >> can't just replace: >> >> #ifdef TARGET_ARCH_abc >> >> with >> >> #ifdef abc >> >> because the "abc"'s may not be mutually exclusive. In our case ARM and >> AARCH64 are both defined and are both needed. In contrast >> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent the >> architecture in this context. >> >> Thanks, >> David >> >>> Thanks, >>> David >>> >>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>> >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>> >>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>> >>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >> appends.h >>>>>>>>> instead? >>>>>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>> similar everywhere. >>>>>>> >>>>>>> We actually need this as the simple arch names need not be mutually >>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>>>>> construct in the correct order. ;-) >>>>>> They should be mutually exclusive, as they are set in CompileJvm.gmk >>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>> >>>>> Unfortunately we also have -DARM coming in from the closed part of >>>>> spec.gmk as we don't use AARCH64 for our port. So we get both defined >>>>> and try to include two platform files. >>>>> >>>>> Not sure how to try and resolve this yet. Trying to understand what the >>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are not >>>>> overriding it for our port - which I think is the current problem, but >>>>> changing it may break something else. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Best regards, >>>>>> Goetz >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>> >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>> >>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> thanks for looking at all these files in more detail! >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>> >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> Again thanks for tackling this! >>>>>>>>> >>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I made a new webrev: >>>>>>>>>> - '_' is added in makefile >>>>>>>>>> - uses Kim's macros >>>>>>>>>> - macros are capitalized >>>>>>>>>> - more comments in macros.hpp >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>> newPfmIncl/webrev.02/ >>>>>>>>> >>>>>>>>> Generally looks okay, a couple of clarifications and comments >> below. >>>>>>>>> >>>>>>>>> >>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>> >>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>> affects the generated files right? >>>>>>>> Yes. >>>>>>>>> For our closed ports we still have >>>>>>>>> the _32/_64 source files in a common arch directory, but I don't >>>>>>>>> think >>>>>>>>> that needs to be reflected in the generated files. (Sorry I >>>>>>>>> haven't had >>>>>>>>> the time yet to apply this patch and see what needs to be changed >> on >>>>> the >>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>> If I run plain configure, it generates a directory that has the >>>>>>>> word size >>>>>>>> in it's name: >>>>>>>> linux-x86_64-normal-server-release >>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>> linux-x86-normal-server-release, >>>>>>>> so I figured this should be fine. >>>>>>> >>>>>>> Yes generated files are fine. >>>>>>> >>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>> >>>>>>>>> Hmm but this change assumes no more _32/_64 header files if I >>>>>>>>> read it >>>>>>>>> right ?? So I'll need a common file that dispatches internally for >>>>>>>>> 32-bit and 64-bit. >>>>>>>> Yes. >>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>> stubRoutines >>>>>>>> But this was rather small. And there anyways was a common file >>>>>>>> that was included in both. >>>>>>>> >>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>> >>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>>>>>> switch(OS) statement: >>>>>>>>> >>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>> ... >>>>>>>>> >>>>>>>>> ie something like: >>>>>>>>> >>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>> >>>>>>>>> ? :) >>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>> Actually I think the implementation should be moved to >>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>> >>>>>>>>> Not clear why the platform include can simply be elided here ?? >>>>>>>> It already includes code/nativeInst.hpp, which is the umbrella header >>>>>>>> for all the platform files. >>>>>>>> >>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>> >>>>>>>>> Shouldn't: >>>>>>>>> >>>>>>>>> ! #endif // !LP64 >>>>>>>>> >>>>>>>>> be: >>>>>>>>> >>>>>>>>> ! #endif // LP64 >>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>> >>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>> >>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >> appends.h >>>>>>>>> instead? >>>>>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>> similar everywhere. >>>>>>> >>>>>>> We actually need this as the simple arch names need not be mutually >>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if-else >>>>>>> construct in the correct order. ;-) >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>> >>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>> >>>>>>>>> #ifndef _WINDOWS >>>>>>>>> #include >>>>>>>>> #endif >>>>>>>>> #ifdef __APPLE__ >>>>>>>>> ... >>>>>>>>> #endif >>>>>>>>> ? >>>>>>>> Fixed. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming >> from >>>>> the >>>>>>>>> compiler itself? >>>>>>>> I wondered about that, too. Therefore I defined WINDOWS in the >>>>>>>> prototype webrev. Then I saw that our build is defining - >> D_WINDOWS >>>>>>> *and* -DWIN32, >>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>> Eventually both should be replaced by WINDOWS, but not in this >>>>>>>> change. >>>>>>>> >>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>> >>>>>>>>> Don't understand the point of this: >>>>>>>>> >>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>> >>>>>>>>> also typo: littel >>>>>>>> I just copied the linux_ppc code and removed the unused >>>>> implementation. >>>>>>>> I wanted to document why there is this empty file. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>>> >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>> >>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> HI Kim, >>>>>>>>>>>> >>>>>>>>>>>> thanks for this version of the macros, it's working on all the >>>>> platforms >>>>>>>>>>>> I can build. >>>>>>>>>>>> >>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and not >>>>>>>>>>>> on the >>>>>>>>>>>> command line. This way, parts of the name construction are in >>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But >> constructing >>>>>>>>>>>> the search path is also in the makefile, and uses the very same >>>>> string >>>>>>>>>>>> as the file suffixes. (Without '_', one could include that in the >>>>> macro, >>>>>>>>> too.) >>>>>>>>>>>> >>>>>>>>>>>> But overall, I consider this a detail and am as fine with your >>>>>>>>>>>> solution >>>>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 etc >>>>>>>>>>>> problems are avoided. >>>>>>>>>>>> >>>>>>>>>>>> Any more opinions whether the macros should be upper case? >>>>>>>>>>> >>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>> >>>>>>>>>>>>>> please take into account that these macros are only used >> within >>>>> 20 >>>>>>>>> lines >>>>>>>>>>> of >>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to understand >> is >>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu and .hpp/.inline.hpp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>>>>>> editing the >>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>> I'm working on the s390 port, and posted my current progress >>>>>>> claiming >>>>>>>>>>>>>> that the biggest shared change I need to do is adding the >>>>> #includes. >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed in that >>>>>>> discussion >>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> I think I see what happened to the email thread for me; it looks >>>>> like >>>>>>> one >>>>>>>>> of >>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not >> hotspot- >>>>>>>>> runtime- >>>>>>>>>>>>> dev, >>>>>>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>>>>>> >>>>>>>>>>>>> I like the idea, just quibbling over details. I've only >>>>>>>>>>>>> reviewed >>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the >>>>>>>>>>>>> details >>>>>>>>>>>>> are settled. >>>>>>>>>>>>> >>>>>>>>>>>>> ---------------------------------------------------------------------------- >> -- >>>>>>>>>>>>> >>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines that >> spoil >>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, sparc=1. >>>>>>>>>>>>> >>>>>>>>>>>>> This issue can be dodged by making the leading underscore >> part >>>>> of >>>>>>> the >>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>> use >>>>>>>>>>>>> instead >>>>>>>>>>>>> >>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>>>>>>> 68 - >>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>> \ >>>>>>>>>>>>> >>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>> >>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>> >>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>> #define os_header_stem(basename) >> PASTE_TOKENS(basename, >>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>> >>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>> #define os_header(basename) >>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>> >>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>> >>>>>>>>>>>>> If some future build system wants brackets instead of >>>>>>>>>>>>> strings, just >>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>> >>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but >>>>>>>>>>>>> that's >>>>> true >>>>>>>>>>>>> for the webrev.01 code too. But note that underscore >> followed >>>>> by a >>>>>>>>>>>>> lowercase letter is not in the reserved word pattern for C/C++. >>>>>>>>>>>>> >>>>>>>>>>>>> BTW, my preference would be to use uppercase for the macro >>>>>>> names. >>>>>>>>> I >>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>> >>>>>>>>>>>>> ---------------------------------------------------------------------------- >> -- >>>>>>>>>>>>> >>>>>>>>>>>> From goetz.lindenmaier at sap.com Tue Jul 19 09:08:18 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Jul 2016 09:08:18 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> Message-ID: <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> Hi David, > I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > workaround is obscure - you have to know that the Open Aarch64 port > defines AARCH64 but not ARM and so that code is for the Open port use > only. There's no issue for the OS defines, but I wonder - just something > to thing about - if TARGET_ARCH_xxx should be restored? Well, I think TARGET_ARCH_xxx always was xxx. And I'm uneasy that it is no more. How do you handle that? You have to check every AARCH change by RedHat against your closed port? I don't know about the closed stuff, but aarch came up recently, and before that it sure was equivalent. And it still is the case for openJDK. Below output is grepped out of the make//platform_ files in jdk8/hotspot, and none of the cpu/arch names are defined twice. Zero is an exception I guess, as it's no real cpu/arch. Best regards, Goetz. sysdefs = -DAIX -DPPC64 sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE -DIA32 sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO -D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, July 19, 2016 10:47 AM > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Thanks Goetz. Will get back to you asap if there are any further issues, > but the incremental changes look okay. > > On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I added macros for C headers: > > CPU_HEADER_H() etc. > > and fixed the other issues mentioned by David and Coleen in this new > webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.03/ > > > > I also added comments that AARCH64 and ARM are defined > > at the same time. > > > > Further I edited vmStructs_jvmci.cpp to > > #if defined(AARCH64) && !defined(ARM) > > I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > workaround is obscure - you have to know that the Open Aarch64 port > defines AARCH64 but not ARM and so that code is for the Open port use > only. There's no issue for the OS defines, but I wonder - just something > to thing about - if TARGET_ARCH_xxx should be restored? > > Thanks, > David > > > My incremental changes are in this patch: > > http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.03/incremental_changes.patch > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Tuesday, July 19, 2016 3:37 AM > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> Hi Goetz, > >> > >> On 18/07/2016 10:23 PM, David Holmes wrote: > >>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>> Hi David, > >>>> > >>>> I'll introduce CPU_HEADER_H, but actually this should be fixed > >>>> in the closed code. > >>> > >>> Bear with me, I'm trying to figure out how to do just that. :) > >>> > >>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef is > not > >>> going to work for our closed ports, unless I change that value to match > >>> the open naming scheme. But that in turn will lead to other problems as > >>> we also need that value the way it is currently defined. > >>> > >>> I'll tackle this again in the morning when I'm fresher. > >> > >> Sorry but this really does need the CPU_HEADER_H macro. In general you > >> can't just replace: > >> > >> #ifdef TARGET_ARCH_abc > >> > >> with > >> > >> #ifdef abc > >> > >> because the "abc"'s may not be mutually exclusive. In our case ARM and > >> AARCH64 are both defined and are both needed. In contrast > >> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent the > >> architecture in this context. > >> > >> Thanks, > >> David > >> > >>> Thanks, > >>> David > >>> > >>> > >>>> Best regards, > >>>> Goetz. > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>> > >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>> > >>>>> Hi Goetz, > >>>>> > >>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>> Hi David, > >>>>>> > >>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>> > >>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>> > >>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that > >> appends.h > >>>>>>>>> instead? > >>>>>>>> I'll need one for OS, one for CPU, and each will be used only once. > >>>>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>>>> similar everywhere. > >>>>>>> > >>>>>>> We actually need this as the simple arch names need not be > mutually > >>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- > else > >>>>>>> construct in the correct order. ;-) > >>>>>> They should be mutually exclusive, as they are set in > CompileJvm.gmk > >>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>> > >>>>> Unfortunately we also have -DARM coming in from the closed part of > >>>>> spec.gmk as we don't use AARCH64 for our port. So we get both > defined > >>>>> and try to include two platform files. > >>>>> > >>>>> Not sure how to try and resolve this yet. Trying to understand what > the > >>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are > not > >>>>> overriding it for our port - which I think is the current problem, but > >>>>> changing it may break something else. > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> > >>>>>> Best regards, > >>>>>> Goetz > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>>> > >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>> dev at openjdk.java.net > >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>> > >>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>> > >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>> dev at openjdk.java.net > >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>> > >>>>>>>>> Hi Goetz, > >>>>>>>>> > >>>>>>>>> Again thanks for tackling this! > >>>>>>>>> > >>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I made a new webrev: > >>>>>>>>>> - '_' is added in makefile > >>>>>>>>>> - uses Kim's macros > >>>>>>>>>> - macros are capitalized > >>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>> > >>>>>>>>> Generally looks okay, a couple of clarifications and comments > >> below. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>> > >>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>> affects the generated files right? > >>>>>>>> Yes. > >>>>>>>>> For our closed ports we still have > >>>>>>>>> the _32/_64 source files in a common arch directory, but I don't > >>>>>>>>> think > >>>>>>>>> that needs to be reflected in the generated files. (Sorry I > >>>>>>>>> haven't had > >>>>>>>>> the time yet to apply this patch and see what needs to be > changed > >> on > >>>>> the > >>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>> If I run plain configure, it generates a directory that has the > >>>>>>>> word size > >>>>>>>> in it's name: > >>>>>>>> linux-x86_64-normal-server-release > >>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>> linux-x86-normal-server-release, > >>>>>>>> so I figured this should be fine. > >>>>>>> > >>>>>>> Yes generated files are fine. > >>>>>>> > >>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>> > >>>>>>>>> Hmm but this change assumes no more _32/_64 header files if I > >>>>>>>>> read it > >>>>>>>>> right ?? So I'll need a common file that dispatches internally for > >>>>>>>>> 32-bit and 64-bit. > >>>>>>>> Yes. > >>>>>>>> There is a single file in cpu/x86 where this did not hold: > >>>>>>>> stubRoutines > >>>>>>>> But this was rather small. And there anyways was a common file > >>>>>>>> that was included in both. > >>>>>>>> > >>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>> > >>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind of > >>>>>>>>> switch(OS) statement: > >>>>>>>>> > >>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>> ... > >>>>>>>>> > >>>>>>>>> ie something like: > >>>>>>>>> > >>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>> > >>>>>>>>> ? :) > >>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>>>>>>> Actually I think the implementation should be moved to > >>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>> > >>>>>>>>> Not clear why the platform include can simply be elided here ?? > >>>>>>>> It already includes code/nativeInst.hpp, which is the umbrella > header > >>>>>>>> for all the platform files. > >>>>>>>> > >>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>> > >>>>>>>>> Shouldn't: > >>>>>>>>> > >>>>>>>>> ! #endif // !LP64 > >>>>>>>>> > >>>>>>>>> be: > >>>>>>>>> > >>>>>>>>> ! #endif // LP64 > >>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>> > >>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>> > >>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that > >> appends.h > >>>>>>>>> instead? > >>>>>>>> I'll need one for OS, one for CPU, and each will be used only once. > >>>>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>>>> similar everywhere. > >>>>>>> > >>>>>>> We actually need this as the simple arch names need not be > mutually > >>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- > else > >>>>>>> construct in the correct order. ;-) > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> ----- > >>>>>>> > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>> > >>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>> > >>>>>>>>> #ifndef _WINDOWS > >>>>>>>>> #include > >>>>>>>>> #endif > >>>>>>>>> #ifdef __APPLE__ > >>>>>>>>> ... > >>>>>>>>> #endif > >>>>>>>>> ? > >>>>>>>> Fixed. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming > >> from > >>>>> the > >>>>>>>>> compiler itself? > >>>>>>>> I wondered about that, too. Therefore I defined WINDOWS in the > >>>>>>>> prototype webrev. Then I saw that our build is defining - > >> D_WINDOWS > >>>>>>> *and* -DWIN32, > >>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>> Eventually both should be replaced by WINDOWS, but not in this > >>>>>>>> change. > >>>>>>>> > >>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>> > >>>>>>>>> Don't understand the point of this: > >>>>>>>>> > >>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>> > >>>>>>>>> also typo: littel > >>>>>>>> I just copied the linux_ppc code and removed the unused > >>>>> implementation. > >>>>>>>> I wanted to document why there is this empty file. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Goetz. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>>> > >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>> > >>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>> HI Kim, > >>>>>>>>>>>> > >>>>>>>>>>>> thanks for this version of the macros, it's working on all the > >>>>> platforms > >>>>>>>>>>>> I can build. > >>>>>>>>>>>> > >>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and not > >>>>>>>>>>>> on the > >>>>>>>>>>>> command line. This way, parts of the name construction are > in > >>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But > >> constructing > >>>>>>>>>>>> the search path is also in the makefile, and uses the very > same > >>>>> string > >>>>>>>>>>>> as the file suffixes. (Without '_', one could include that in the > >>>>> macro, > >>>>>>>>> too.) > >>>>>>>>>>>> > >>>>>>>>>>>> But overall, I consider this a detail and am as fine with your > >>>>>>>>>>>> solution > >>>>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 > etc > >>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>> > >>>>>>>>>>>> Any more opinions whether the macros should be upper case? > >>>>>>>>>>> > >>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> David > >>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Goetz. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- > >>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > files. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> please take into account that these macros are only used > >> within > >>>>> 20 > >>>>>>>>> lines > >>>>>>>>>>> of > >>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to > understand > >> is > >>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to > >>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > and .hpp/.inline.hpp. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I really would appreciate if I don't have to spend days > >>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>> I'm working on the s390 port, and posted my current > progress > >>>>>>> claiming > >>>>>>>>>>>>>> that the biggest shared change I need to do is adding the > >>>>> #includes. > >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed in that > >>>>>>> discussion > >>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > >>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think I see what happened to the email thread for me; it > looks > >>>>> like > >>>>>>> one > >>>>>>>>> of > >>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not > >> hotspot- > >>>>>>>>> runtime- > >>>>>>>>>>>>> dev, > >>>>>>>>>>>>> and I was not subscribed to the compiler list this morning. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I like the idea, just quibbling over details. I've only > >>>>>>>>>>>>> reviewed > >>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the > >>>>>>>>>>>>> details > >>>>>>>>>>>>> are settled. > >>>>>>>>>>>>> > >>>>>>>>>>>>> ------------------------------------------------------------------------- > --- > >> -- > >>>>>>>>>>>>> > >>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines that > >> spoil > >>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, > sparc=1. > >>>>>>>>>>>>> > >>>>>>>>>>>>> This issue can be dodged by making the leading underscore > >> part > >>>>> of > >>>>>>> the > >>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>> use > >>>>>>>>>>>>> instead > >>>>>>>>>>>>> > >>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > >>>>>>>>>>>>> 68 - > >>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>> \ > >>>>>>>>>>>>> > >>>>>>>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>> > >>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>> #define os_header_stem(basename) > >> PASTE_TOKENS(basename, > >>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>> > >>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>> > >>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>> > >>>>>>>>>>>>> If some future build system wants brackets instead of > >>>>>>>>>>>>> strings, just > >>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but > >>>>>>>>>>>>> that's > >>>>> true > >>>>>>>>>>>>> for the webrev.01 code too. But note that underscore > >> followed > >>>>> by a > >>>>>>>>>>>>> lowercase letter is not in the reserved word pattern for > C/C++. > >>>>>>>>>>>>> > >>>>>>>>>>>>> BTW, my preference would be to use uppercase for the > macro > >>>>>>> names. > >>>>>>>>> I > >>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>> > >>>>>>>>>>>>> ------------------------------------------------------------------------- > --- > >> -- > >>>>>>>>>>>>> > >>>>>>>>>>>> From david.holmes at oracle.com Tue Jul 19 11:23:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jul 2016 21:23:23 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> Message-ID: On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > Hi David, > >> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >> workaround is obscure - you have to know that the Open Aarch64 port >> defines AARCH64 but not ARM and so that code is for the Open port use >> only. There's no issue for the OS defines, but I wonder - just something >> to thing about - if TARGET_ARCH_xxx should be restored? > > Well, I think TARGET_ARCH_xxx always was xxx. > And I'm uneasy that it is no more. How do you handle that? You have to > check every AARCH change by RedHat against your closed port? The sources for the two ports are distinct so the only place we have to have a convention is in shared code that has CPU specific stuff and in the build files. The open Aarch64 port sets (among others): -DTARGET_ARCH_aarch64 -DAARCH64 the closed port sets -DTARGET_ARCH_arm -DARM -DAARCH64 so it is the value of TARGET_ARCH_xxx that distinguishes them. Whenever you saw TARGET_ARCH_arm in open shared code it is/was referring to our closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 port. Of course TARGET_OS_ARCH_linux_xxx is in the same position. We need to keep a clear distinction. Using the combination of AARCH64 and ARM is not so clear. You could easily have similar issues with other port groups - eg ppc64 vs ppc32 vs ppcle. Thanks, David > I don't know about the closed stuff, but aarch came up recently, and > before that it sure was equivalent. And it still is the case for openJDK. > > Below output is grepped out of the make//platform_ files in > jdk8/hotspot, and none of the cpu/arch names are defined twice. > Zero is an exception I guess, as it's no real cpu/arch. > > Best regards, > Goetz. > > sysdefs = -DAIX -DPPC64 > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO -D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 > sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, July 19, 2016 10:47 AM >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> Thanks Goetz. Will get back to you asap if there are any further issues, >> but the incremental changes look okay. >> >> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I added macros for C headers: >>> CPU_HEADER_H() etc. >>> and fixed the other issues mentioned by David and Coleen in this new >> webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.03/ >>> >>> I also added comments that AARCH64 and ARM are defined >>> at the same time. >>> >>> Further I edited vmStructs_jvmci.cpp to >>> #if defined(AARCH64) && !defined(ARM) >> >> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >> workaround is obscure - you have to know that the Open Aarch64 port >> defines AARCH64 but not ARM and so that code is for the Open port use >> only. There's no issue for the OS defines, but I wonder - just something >> to thing about - if TARGET_ARCH_xxx should be restored? >> >> Thanks, >> David >> >>> My incremental changes are in this patch: >>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >> newPfmIncl/webrev.03/incremental_changes.patch >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> Hi Goetz, >>>> >>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed >>>>>> in the closed code. >>>>> >>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>> >>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef is >> not >>>>> going to work for our closed ports, unless I change that value to match >>>>> the open naming scheme. But that in turn will lead to other problems as >>>>> we also need that value the way it is currently defined. >>>>> >>>>> I'll tackle this again in the morning when I'm fresher. >>>> >>>> Sorry but this really does need the CPU_HEADER_H macro. In general you >>>> can't just replace: >>>> >>>> #ifdef TARGET_ARCH_abc >>>> >>>> with >>>> >>>> #ifdef abc >>>> >>>> because the "abc"'s may not be mutually exclusive. In our case ARM and >>>> AARCH64 are both defined and are both needed. In contrast >>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent the >>>> architecture in this context. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>> >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>> >>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>> >>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >>>> appends.h >>>>>>>>>>> instead? >>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>>>> similar everywhere. >>>>>>>>> >>>>>>>>> We actually need this as the simple arch names need not be >> mutually >>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- >> else >>>>>>>>> construct in the correct order. ;-) >>>>>>>> They should be mutually exclusive, as they are set in >> CompileJvm.gmk >>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>> >>>>>>> Unfortunately we also have -DARM coming in from the closed part of >>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get both >> defined >>>>>>> and try to include two platform files. >>>>>>> >>>>>>> Not sure how to try and resolve this yet. Trying to understand what >> the >>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we are >> not >>>>>>> overriding it for our port - which I think is the current problem, but >>>>>>> changing it may break something else. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>> >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>>> >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>> >>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Generally looks okay, a couple of clarifications and comments >>>> below. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>> >>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>> affects the generated files right? >>>>>>>>>> Yes. >>>>>>>>>>> For our closed ports we still have >>>>>>>>>>> the _32/_64 source files in a common arch directory, but I don't >>>>>>>>>>> think >>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I >>>>>>>>>>> haven't had >>>>>>>>>>> the time yet to apply this patch and see what needs to be >> changed >>>> on >>>>>>> the >>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>> If I run plain configure, it generates a directory that has the >>>>>>>>>> word size >>>>>>>>>> in it's name: >>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>> so I figured this should be fine. >>>>>>>>> >>>>>>>>> Yes generated files are fine. >>>>>>>>> >>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>> >>>>>>>>>>> Hmm but this change assumes no more _32/_64 header files if I >>>>>>>>>>> read it >>>>>>>>>>> right ?? So I'll need a common file that dispatches internally for >>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>> Yes. >>>>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>>>> stubRoutines >>>>>>>>>> But this was rather small. And there anyways was a common file >>>>>>>>>> that was included in both. >>>>>>>>>> >>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>> >>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>>>>>>>> switch(OS) statement: >>>>>>>>>>> >>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> ie something like: >>>>>>>>>>> >>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>> >>>>>>>>>>> ? :) >>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>>>> Actually I think the implementation should be moved to >>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>> >>>>>>>>>>> Not clear why the platform include can simply be elided here ?? >>>>>>>>>> It already includes code/nativeInst.hpp, which is the umbrella >> header >>>>>>>>>> for all the platform files. >>>>>>>>>> >>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>> >>>>>>>>>>> Shouldn't: >>>>>>>>>>> >>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>> >>>>>>>>>>> be: >>>>>>>>>>> >>>>>>>>>>> ! #endif // LP64 >>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>> >>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>> >>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >>>> appends.h >>>>>>>>>>> instead? >>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only once. >>>>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>>>> similar everywhere. >>>>>>>>> >>>>>>>>> We actually need this as the simple arch names need not be >> mutually >>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- >> else >>>>>>>>> construct in the correct order. ;-) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>> >>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>> >>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>> #include >>>>>>>>>>> #endif >>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>> ... >>>>>>>>>>> #endif >>>>>>>>>>> ? >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that coming >>>> from >>>>>>> the >>>>>>>>>>> compiler itself? >>>>>>>>>> I wondered about that, too. Therefore I defined WINDOWS in the >>>>>>>>>> prototype webrev. Then I saw that our build is defining - >>>> D_WINDOWS >>>>>>>>> *and* -DWIN32, >>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>> Eventually both should be replaced by WINDOWS, but not in this >>>>>>>>>> change. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>> >>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>> >>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>> >>>>>>>>>>> also typo: littel >>>>>>>>>> I just copied the linux_ppc code and removed the unused >>>>>>> implementation. >>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>> >>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks for this version of the macros, it's working on all the >>>>>>> platforms >>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and not >>>>>>>>>>>>>> on the >>>>>>>>>>>>>> command line. This way, parts of the name construction are >> in >>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But >>>> constructing >>>>>>>>>>>>>> the search path is also in the makefile, and uses the very >> same >>>>>>> string >>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include that in the >>>>>>> macro, >>>>>>>>>>> too.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> But overall, I consider this a detail and am as fine with your >>>>>>>>>>>>>> solution >>>>>>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 >> etc >>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any more opinions whether the macros should be upper case? >>>>>>>>>>>>> >>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> please take into account that these macros are only used >>>> within >>>>>>> 20 >>>>>>>>>>> lines >>>>>>>>>>>>> of >>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to >> understand >>>> is >>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my current >> progress >>>>>>>>> claiming >>>>>>>>>>>>>>>> that the biggest shared change I need to do is adding the >>>>>>> #includes. >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed in that >>>>>>>>> discussion >>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- >>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think I see what happened to the email thread for me; it >> looks >>>>>>> like >>>>>>>>> one >>>>>>>>>>> of >>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not >>>> hotspot- >>>>>>>>>>> runtime- >>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only >>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the >>>>>>>>>>>>>>> details >>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------------- >> --- >>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines that >>>> spoil >>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, >> sparc=1. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This issue can be dodged by making the leading underscore >>>> part >>>>>>> of >>>>>>>>> the >>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>> use >>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ >>>>>>>>>>>>>>> 68 - >>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>> \ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>> #define os_header_stem(basename) >>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If some future build system wants brackets instead of >>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but >>>>>>>>>>>>>>> that's >>>>>>> true >>>>>>>>>>>>>>> for the webrev.01 code too. But note that underscore >>>> followed >>>>>>> by a >>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern for >> C/C++. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for the >> macro >>>>>>>>> names. >>>>>>>>>>> I >>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------------- >> --- >>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Tue Jul 19 12:12:33 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Jul 2016 12:12:33 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> Message-ID: Hi David, we also have "closed ports", currently HPUX, ia64 and s390. (Parisc is gone, puh!). We basically patch all the shared changes onto the sources after getting them via our licensee channel. I think you should fix your closed port not to re-use the names of the main openJdk platforms! I have no idea what hardware is addressed by your closed ports, nor how you merge sources. Is there also a port that sets -DTARGET_ARCH_arm -DARM -DARM32 ? To fix this either you define #if defined(ARM) && defined(_LP64) #define ARM64 #endif in macros.hpp or you set -DARM64 on the command line. Then you replace all #ifdef AARCH64 by #if defined(AARCH64) || defined(ARM64) or maybe it suffices altogether f you replace #ifdef AARCH64 by #if defined(AARCH64) || defined(ARM) For ppc, when we did the port we knew (and that's all we knew) that you have a 32-bit port. Therefore we set up these macros as on x86, where there is one for the arch (X86) and two for LP64/!LP64 (IA32, AMD64). This allowed to separate code for the closed port (guarded by PPC32), the open port (PPC64) and shared for both (PPC). But I don't think it is necessary to do any further changes now, assuming my change works for you as I adapted it. So we're all set I guess! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, July 19, 2016 1:23 PM > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > >> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > >> workaround is obscure - you have to know that the Open Aarch64 port > >> defines AARCH64 but not ARM and so that code is for the Open port use > >> only. There's no issue for the OS defines, but I wonder - just something > >> to thing about - if TARGET_ARCH_xxx should be restored? > > > > Well, I think TARGET_ARCH_xxx always was xxx. > > And I'm uneasy that it is no more. How do you handle that? You have to > > check every AARCH change by RedHat against your closed port? > > The sources for the two ports are distinct so the only place we have to > have a convention is in shared code that has CPU specific stuff and in > the build files. > > The open Aarch64 port sets (among others): > -DTARGET_ARCH_aarch64 > -DAARCH64 > > the closed port sets > > -DTARGET_ARCH_arm > -DARM > -DAARCH64 > > so it is the value of TARGET_ARCH_xxx that distinguishes them. Whenever > you saw TARGET_ARCH_arm in open shared code it is/was referring to our > closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 port. > > Of course TARGET_OS_ARCH_linux_xxx is in the same position. > > We need to keep a clear distinction. Using the combination of AARCH64 > and ARM is not so clear. > > You could easily have similar issues with other port groups - eg ppc64 > vs ppc32 vs ppcle. > > Thanks, > David > > > I don't know about the closed stuff, but aarch came up recently, and > > before that it sure was equivalent. And it still is the case for openJDK. > > > > Below output is grepped out of the make//platform_ files in > > jdk8/hotspot, and none of the cpu/arch names are defined twice. > > Zero is an exception I guess, as it's no real cpu/arch. > > > > Best regards, > > Goetz. > > > > sysdefs = -DAIX -DPPC64 > > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > > sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - > DAMD64 > > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > > sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP > > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > > sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO - > D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > > sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > > sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 > > sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > > sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > > sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > > sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > > sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > > sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > > sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > > sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > > sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > > sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > > sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > > sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > > sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > > sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > > sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Tuesday, July 19, 2016 10:47 AM > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> Thanks Goetz. Will get back to you asap if there are any further issues, > >> but the incremental changes look okay. > >> > >> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I added macros for C headers: > >>> CPU_HEADER_H() etc. > >>> and fixed the other issues mentioned by David and Coleen in this new > >> webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.03/ > >>> > >>> I also added comments that AARCH64 and ARM are defined > >>> at the same time. > >>> > >>> Further I edited vmStructs_jvmci.cpp to > >>> #if defined(AARCH64) && !defined(ARM) > >> > >> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > >> workaround is obscure - you have to know that the Open Aarch64 port > >> defines AARCH64 but not ARM and so that code is for the Open port use > >> only. There's no issue for the OS defines, but I wonder - just something > >> to thing about - if TARGET_ARCH_xxx should be restored? > >> > >> Thanks, > >> David > >> > >>> My incremental changes are in this patch: > >>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >> newPfmIncl/webrev.03/incremental_changes.patch > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>> Hi David, > >>>>>> > >>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed > >>>>>> in the closed code. > >>>>> > >>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>> > >>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef > is > >> not > >>>>> going to work for our closed ports, unless I change that value to > match > >>>>> the open naming scheme. But that in turn will lead to other problems > as > >>>>> we also need that value the way it is currently defined. > >>>>> > >>>>> I'll tackle this again in the morning when I'm fresher. > >>>> > >>>> Sorry but this really does need the CPU_HEADER_H macro. In general > you > >>>> can't just replace: > >>>> > >>>> #ifdef TARGET_ARCH_abc > >>>> > >>>> with > >>>> > >>>> #ifdef abc > >>>> > >>>> because the "abc"'s may not be mutually exclusive. In our case ARM > and > >>>> AARCH64 are both defined and are both needed. In contrast > >>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent > the > >>>> architecture in this context. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> > >>>>>> Best regards, > >>>>>> Goetz. > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>>> > >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>> dev at openjdk.java.net > >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>> > >>>>>>> Hi Goetz, > >>>>>>> > >>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>> > >>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>>>> > >>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that > >>>> appends.h > >>>>>>>>>>> instead? > >>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only > once. > >>>>>>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>>>>>> similar everywhere. > >>>>>>>>> > >>>>>>>>> We actually need this as the simple arch names need not be > >> mutually > >>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- > >> else > >>>>>>>>> construct in the correct order. ;-) > >>>>>>>> They should be mutually exclusive, as they are set in > >> CompileJvm.gmk > >>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>> > >>>>>>> Unfortunately we also have -DARM coming in from the closed part > of > >>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get both > >> defined > >>>>>>> and try to include two platform files. > >>>>>>> > >>>>>>> Not sure how to try and resolve this yet. Trying to understand what > >> the > >>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we > are > >> not > >>>>>>> overriding it for our port - which I think is the current problem, but > >>>>>>> changing it may break something else. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> > >>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Goetz > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>> > >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>> dev at openjdk.java.net > >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>> > >>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> Hi David, > >>>>>>>>>> > >>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>>> > >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>> > >>>>>>>>>>> Hi Goetz, > >>>>>>>>>>> > >>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>> > >>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>> > >>>>>>>>>>> Generally looks okay, a couple of clarifications and comments > >>>> below. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>> > >>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>> affects the generated files right? > >>>>>>>>>> Yes. > >>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>> the _32/_64 source files in a common arch directory, but I > don't > >>>>>>>>>>> think > >>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I > >>>>>>>>>>> haven't had > >>>>>>>>>>> the time yet to apply this patch and see what needs to be > >> changed > >>>> on > >>>>>>> the > >>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>> If I run plain configure, it generates a directory that has the > >>>>>>>>>> word size > >>>>>>>>>> in it's name: > >>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>> so I figured this should be fine. > >>>>>>>>> > >>>>>>>>> Yes generated files are fine. > >>>>>>>>> > >>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>> > >>>>>>>>>>> Hmm but this change assumes no more _32/_64 header files if > I > >>>>>>>>>>> read it > >>>>>>>>>>> right ?? So I'll need a common file that dispatches internally for > >>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>> Yes. > >>>>>>>>>> There is a single file in cpu/x86 where this did not hold: > >>>>>>>>>> stubRoutines > >>>>>>>>>> But this was rather small. And there anyways was a common file > >>>>>>>>>> that was included in both. > >>>>>>>>>> > >>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>> > >>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind of > >>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>> > >>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>> ... > >>>>>>>>>>> > >>>>>>>>>>> ie something like: > >>>>>>>>>>> > >>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>> > >>>>>>>>>>> ? :) > >>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>>>>>>>>> Actually I think the implementation should be moved to > >>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> > >>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>> > >>>>>>>>>>> Not clear why the platform include can simply be elided here ?? > >>>>>>>>>> It already includes code/nativeInst.hpp, which is the umbrella > >> header > >>>>>>>>>> for all the platform files. > >>>>>>>>>> > >>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>> > >>>>>>>>>>> Shouldn't: > >>>>>>>>>>> > >>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>> > >>>>>>>>>>> be: > >>>>>>>>>>> > >>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> > >>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>> > >>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>>>> > >>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that > >>>> appends.h > >>>>>>>>>>> instead? > >>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only > once. > >>>>>>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>>>>>> similar everywhere. > >>>>>>>>> > >>>>>>>>> We actually need this as the simple arch names need not be > >> mutually > >>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- > >> else > >>>>>>>>> construct in the correct order. ;-) > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> > >>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>> > >>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>> > >>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>> #include > >>>>>>>>>>> #endif > >>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>> ... > >>>>>>>>>>> #endif > >>>>>>>>>>> ? > >>>>>>>>>> Fixed. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that > coming > >>>> from > >>>>>>> the > >>>>>>>>>>> compiler itself? > >>>>>>>>>> I wondered about that, too. Therefore I defined WINDOWS in > the > >>>>>>>>>> prototype webrev. Then I saw that our build is defining - > >>>> D_WINDOWS > >>>>>>>>> *and* -DWIN32, > >>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>> Eventually both should be replaced by WINDOWS, but not in this > >>>>>>>>>> change. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> > >>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>> > >>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>> > >>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>> > >>>>>>>>>>> also typo: littel > >>>>>>>>>> I just copied the linux_ppc code and removed the unused > >>>>>>> implementation. > >>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> David > >>>>>>>>>>> ----- > >>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Goetz. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >>>> Barrett > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> thanks for this version of the macros, it's working on all the > >>>>>>> platforms > >>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and > not > >>>>>>>>>>>>>> on the > >>>>>>>>>>>>>> command line. This way, parts of the name construction > are > >> in > >>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But > >>>> constructing > >>>>>>>>>>>>>> the search path is also in the makefile, and uses the very > >> same > >>>>>>> string > >>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include that in > the > >>>>>>> macro, > >>>>>>>>>>> too.) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> But overall, I consider this a detail and am as fine with your > >>>>>>>>>>>>>> solution > >>>>>>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 > >> etc > >>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Any more opinions whether the macros should be upper > case? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- > >>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> please take into account that these macros are only > used > >>>> within > >>>>>>> 20 > >>>>>>>>>>> lines > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to > >> understand > >>>> is > >>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to > >>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend days > >>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my current > >> progress > >>>>>>>>> claiming > >>>>>>>>>>>>>>>> that the biggest shared change I need to do is adding the > >>>>>>> #includes. > >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > dev/2016- > >>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed in > that > >>>>>>>>> discussion > >>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > dev/2016- > >>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think I see what happened to the email thread for me; it > >> looks > >>>>>>> like > >>>>>>>>> one > >>>>>>>>>>> of > >>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not > >>>> hotspot- > >>>>>>>>>>> runtime- > >>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>> and I was not subscribed to the compiler list this morning. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only > >>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the > >>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ---------------------------------------------------------------------- > --- > >> --- > >>>> -- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines > that > >>>> spoil > >>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, > >> sparc=1. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This issue can be dodged by making the leading > underscore > >>>> part > >>>>>>> of > >>>>>>>>> the > >>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>> use > >>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > \ > >>>>>>>>>>>>>>> 68 - > >>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>> \ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If some future build system wants brackets instead of > >>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but > >>>>>>>>>>>>>>> that's > >>>>>>> true > >>>>>>>>>>>>>>> for the webrev.01 code too. But note that underscore > >>>> followed > >>>>>>> by a > >>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern for > >> C/C++. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for the > >> macro > >>>>>>>>> names. > >>>>>>>>>>> I > >>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ---------------------------------------------------------------------- > --- > >> --- > >>>> -- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> From lois.foltan at oracle.com Tue Jul 19 18:09:00 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 19 Jul 2016 14:09:00 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build Message-ID: <578E6CBC.9010901@oracle.com> Hello, Please review the following fix: Webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ Bug: -Xbootclasspath/a breaks exploded build https://bugs.openjdk.java.net/browse/JDK-8154239 Summary: The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. 215 // The boot class path consists of 3 ordered pieces: 216 // 1. the module/path pairs specified to -Xpatch 217 // -Xpatch:=()* 218 // 2. the base piece 219 // [jimage | build with exploded modules] 220 // 3. boot loader append path 221 // [-Xbootclasspath/a]; [jvmti appended entries] 222 // 223 // The boot loader must obey this order when attempting 224 // to load a class. Testing: Full hotspot nightly testing with a java runtime image build JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build JCK lang & vm with both a java runtime image and an exploded module build Hotspot jtreg tests with both a java runtime image and an exploded module build From claes.redestad at oracle.com Tue Jul 19 19:17:02 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 Jul 2016 21:17:02 +0200 Subject: RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors Message-ID: <578E7CAE.6070705@oracle.com> Hi, please review this bug fix to ensure MemberName::resolveOrNull doesn't throw exceptions when speculatively looking up members that aren't there. HS: http://cr.openjdk.java.net/~redestad/8161588/hs.01 JDK: http://cr.openjdk.java.net/~redestad/8161588/jdk.01 This avoids throwing NoSuchMethodError etc just to be ignored, avoiding a performance penalty when looking things up speculatively (which is key to possible upcoming work to generate more JLI code with jlink). There's a pre-existing issue not dealt with by this fix in that the exceptions thrown in MHN_resolve_Mem are never observed, instead the exceptions thrown from various LinkResolver methods are observed. We could clear all pending exceptions in resolve_MemberName, but this breaks tests that are very particular about which exception is thrown when and where, thus I opted to add the clear_pending boolean to allow clearing the exception conditionally instead, keeping behavior identical for MemberName::resolveOrFail Thanks! /Claes From david.holmes at oracle.com Tue Jul 19 21:58:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 07:58:55 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> Message-ID: Hi Goetz, On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > Hi David, > > we also have "closed ports", currently HPUX, ia64 and s390. > (Parisc is gone, puh!). > We basically patch all the shared changes onto the sources after > getting them via our licensee channel. > I think you should fix your closed port not to re-use the names of the > main openJdk platforms! Nobody "owns" a define of AARCH64 or ARM. We did not want to have to pollute the shared sources with two sets of ifdefs for "64-bit ARM" so we worked with the Open port to ensure that shared code guarded by AARCH64 is suitable for both. We also ensured ARM was used to identify word-size agnostic code and we introduced ARM32 in a handful of places that needed it. And sometimes we have to be careful and ensure that ifdef chains check AARCH64 before they check ARM. This has all been working quite nicely, as the include guards used, for example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which are never defined at the same time (derived from HOTSPOT_TARGET_CPU_ARCH). But the current changes remove those unique defines and, before the HEADER_H forms were introduced, tried to use simple AARCH64 and ARM as include guards, and that doesn't work as they are not mutually exclusive. So what I'm suggesting is just not getting rid of those defines, but keeping them so they can be used as include guards (or other conditional code) when needed, and where the macros are not suitable. Thanks, David ----- > I have no idea what hardware is addressed by your closed ports, > nor how you merge sources. > Is there also a port that sets > -DTARGET_ARCH_arm > -DARM > -DARM32 > ? > > To fix this either you define > #if defined(ARM) && defined(_LP64) > #define ARM64 > #endif > in macros.hpp or you set -DARM64 on the command line. > Then you replace all > #ifdef AARCH64 > by > #if defined(AARCH64) || defined(ARM64) > or maybe it suffices altogether f you replace > #ifdef AARCH64 > by > #if defined(AARCH64) || defined(ARM) > > For ppc, when we did the port we knew (and that's all we knew) > that you have a 32-bit port. Therefore we set up these macros > as on x86, where there is one for the arch (X86) and two for LP64/!LP64 > (IA32, AMD64). This allowed to separate code for the closed port > (guarded by PPC32), the open port (PPC64) and shared for both (PPC). > > But I don't think it is necessary to do any further changes now, assuming > my change works for you as I adapted it. So we're all set I guess! > > Best regards, > Goetz. > > > > > > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, July 19, 2016 1:23 PM >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >>>> workaround is obscure - you have to know that the Open Aarch64 port >>>> defines AARCH64 but not ARM and so that code is for the Open port use >>>> only. There's no issue for the OS defines, but I wonder - just something >>>> to thing about - if TARGET_ARCH_xxx should be restored? >>> >>> Well, I think TARGET_ARCH_xxx always was xxx. >>> And I'm uneasy that it is no more. How do you handle that? You have to >>> check every AARCH change by RedHat against your closed port? >> >> The sources for the two ports are distinct so the only place we have to >> have a convention is in shared code that has CPU specific stuff and in >> the build files. >> >> The open Aarch64 port sets (among others): >> -DTARGET_ARCH_aarch64 >> -DAARCH64 >> >> the closed port sets >> >> -DTARGET_ARCH_arm >> -DARM >> -DAARCH64 >> >> so it is the value of TARGET_ARCH_xxx that distinguishes them. Whenever >> you saw TARGET_ARCH_arm in open shared code it is/was referring to our >> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 port. >> >> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >> >> We need to keep a clear distinction. Using the combination of AARCH64 >> and ARM is not so clear. >> >> You could easily have similar issues with other port groups - eg ppc64 >> vs ppc32 vs ppcle. >> >> Thanks, >> David >> >>> I don't know about the closed stuff, but aarch came up recently, and >>> before that it sure was equivalent. And it still is the case for openJDK. >>> >>> Below output is grepped out of the make//platform_ files in >>> jdk8/hotspot, and none of the cpu/arch names are defined twice. >>> Zero is an exception I guess, as it's no real cpu/arch. >>> >>> Best regards, >>> Goetz. >>> >>> sysdefs = -DAIX -DPPC64 >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - >> DAMD64 >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO - >> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 >>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> Thanks Goetz. Will get back to you asap if there are any further issues, >>>> but the incremental changes look okay. >>>> >>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I added macros for C headers: >>>>> CPU_HEADER_H() etc. >>>>> and fixed the other issues mentioned by David and Coleen in this new >>>> webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >> newPfmIncl/webrev.03/ >>>>> >>>>> I also added comments that AARCH64 and ARM are defined >>>>> at the same time. >>>>> >>>>> Further I edited vmStructs_jvmci.cpp to >>>>> #if defined(AARCH64) && !defined(ARM) >>>> >>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >>>> workaround is obscure - you have to know that the Open Aarch64 port >>>> defines AARCH64 but not ARM and so that code is for the Open port use >>>> only. There's no issue for the OS defines, but I wonder - just something >>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>> >>>> Thanks, >>>> David >>>> >>>>> My incremental changes are in this patch: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed >>>>>>>> in the closed code. >>>>>>> >>>>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>>>> >>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the ifdef >> is >>>> not >>>>>>> going to work for our closed ports, unless I change that value to >> match >>>>>>> the open naming scheme. But that in turn will lead to other problems >> as >>>>>>> we also need that value the way it is currently defined. >>>>>>> >>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>> >>>>>> Sorry but this really does need the CPU_HEADER_H macro. In general >> you >>>>>> can't just replace: >>>>>> >>>>>> #ifdef TARGET_ARCH_abc >>>>>> >>>>>> with >>>>>> >>>>>> #ifdef abc >>>>>> >>>>>> because the "abc"'s may not be mutually exclusive. In our case ARM >> and >>>>>> AARCH64 are both defined and are both needed. In contrast >>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to represent >> the >>>>>> architecture in this context. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>> >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>> >>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>>>> >>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >>>>>> appends.h >>>>>>>>>>>>> instead? >>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only >> once. >>>>>>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>>>>>> similar everywhere. >>>>>>>>>>> >>>>>>>>>>> We actually need this as the simple arch names need not be >>>> mutually >>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- >>>> else >>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>> They should be mutually exclusive, as they are set in >>>> CompileJvm.gmk >>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>> >>>>>>>>> Unfortunately we also have -DARM coming in from the closed part >> of >>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get both >>>> defined >>>>>>>>> and try to include two platform files. >>>>>>>>> >>>>>>>>> Not sure how to try and resolve this yet. Trying to understand what >>>> the >>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we >> are >>>> not >>>>>>>>> overriding it for our port - which I think is the current problem, but >>>>>>>>> changing it may break something else. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>>> >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>> >>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>> >>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>> Generally looks okay, a couple of clarifications and comments >>>>>> below. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>> >>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>> Yes. >>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>> the _32/_64 source files in a common arch directory, but I >> don't >>>>>>>>>>>>> think >>>>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I >>>>>>>>>>>>> haven't had >>>>>>>>>>>>> the time yet to apply this patch and see what needs to be >>>> changed >>>>>> on >>>>>>>>> the >>>>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>>>> If I run plain configure, it generates a directory that has the >>>>>>>>>>>> word size >>>>>>>>>>>> in it's name: >>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>> >>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>> >>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>> >>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 header files if >> I >>>>>>>>>>>>> read it >>>>>>>>>>>>> right ?? So I'll need a common file that dispatches internally for >>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>> Yes. >>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>>>>>> stubRoutines >>>>>>>>>>>> But this was rather small. And there anyways was a common file >>>>>>>>>>>> that was included in both. >>>>>>>>>>>> >>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind of >>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>> >>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> ie something like: >>>>>>>>>>>>> >>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>> >>>>>>>>>>>>> ? :) >>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>>>>>> Actually I think the implementation should be moved to >>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> Not clear why the platform include can simply be elided here ?? >>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the umbrella >>>> header >>>>>>>>>>>> for all the platform files. >>>>>>>>>>>> >>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>> >>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>> >>>>>>>>>>>>> be: >>>>>>>>>>>>> >>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>> >>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>>>> >>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >>>>>> appends.h >>>>>>>>>>>>> instead? >>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only >> once. >>>>>>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>>>>>> similar everywhere. >>>>>>>>>>> >>>>>>>>>>> We actually need this as the simple arch names need not be >>>> mutually >>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an if- >>>> else >>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>> >>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>> >>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>> #include >>>>>>>>>>>>> #endif >>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>> ... >>>>>>>>>>>>> #endif >>>>>>>>>>>>> ? >>>>>>>>>>>> Fixed. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that >> coming >>>>>> from >>>>>>>>> the >>>>>>>>>>>>> compiler itself? >>>>>>>>>>>> I wondered about that, too. Therefore I defined WINDOWS in >> the >>>>>>>>>>>> prototype webrev. Then I saw that our build is defining - >>>>>> D_WINDOWS >>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but not in this >>>>>>>>>>>> change. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>> >>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>> >>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>> >>>>>>>>>>>>> also typo: littel >>>>>>>>>>>> I just copied the linux_ppc code and removed the unused >>>>>>>>> implementation. >>>>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks for this version of the macros, it's working on all the >>>>>>>>> platforms >>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and >> not >>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>> command line. This way, parts of the name construction >> are >>>> in >>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But >>>>>> constructing >>>>>>>>>>>>>>>> the search path is also in the makefile, and uses the very >>>> same >>>>>>>>> string >>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include that in >> the >>>>>>>>> macro, >>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine with your >>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that the linux=1 >>>> etc >>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any more opinions whether the macros should be upper >> case? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot-compiler- >>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> please take into account that these macros are only >> used >>>>>> within >>>>>>>>> 20 >>>>>>>>>>>>> lines >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to >>>> understand >>>>>> is >>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and expands to >>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my current >>>> progress >>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is adding the >>>>>>>>> #includes. >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >> dev/2016- >>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed in >> that >>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >> dev/2016- >>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think I see what happened to the email thread for me; it >>>> looks >>>>>>>>> like >>>>>>>>>>> one >>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but not >>>>>> hotspot- >>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this morning. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only >>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until the >>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ---------------------------------------------------------------------- >> --- >>>> --- >>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines >> that >>>>>> spoil >>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, >>>> sparc=1. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This issue can be dodged by making the leading >> underscore >>>>>> part >>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>> use >>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>> 67 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >> \ >>>>>>>>>>>>>>>>> 68 - >>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>> \ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If some future build system wants brackets instead of >>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, but >>>>>>>>>>>>>>>>> that's >>>>>>>>> true >>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that underscore >>>>>> followed >>>>>>>>> by a >>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern for >>>> C/C++. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for the >>>> macro >>>>>>>>>>> names. >>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ---------------------------------------------------------------------- >> --- >>>> --- >>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Wed Jul 20 08:47:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jul 2016 08:47:25 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <2f401fb4899840c4a299f8e0a3d887fe@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> Message-ID: <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> Hi David, that's great what you are saying and just the design I would expect! > We did not want to have to > pollute the shared sources with two sets of ifdefs for "64-bit ARM" so > we worked with the Open port to ensure that shared code guarded by > AARCH64 is suitable for both. We also ensured ARM was used to identify > word-size agnostic code and we introduced ARM32 in a handful of places > that needed it. And sometimes we have to be careful and ensure that > ifdef chains check AARCH64 before they check ARM. I think as a consequence the open AARCH port should define ARM, too. I checked the occurrences and only see three places where this would have an effect and would have to be fixed somehow: *** share/vm/jvmci/vmStructs_jvmci.cpp: [610] #if defined(AARCH64) && !defined(ARM) ==> Would this break the closed port if defined? (This is the only place where TARGET_ARCH_aarch64 was used) *** share/vm/c1/c1_LIRGenerator.cpp: load_item_force[253] #if !defined(ARM) && !defined(E500V2) ==> Would this break the open port if defined? *** share/vm/c1/c1_Runtime1.cpp: [1154] #ifdef ARM ==> Would this break the open port if defined? All the cases below are pointless. > So what I'm suggesting is just not getting rid of those defines, but > keeping them so they can be used as include guards (or other conditional > code) when needed, and where the macros are not suitable. I think it's quite misleading to have two defines that are 99% equivalent. If we really need a special case here, you should define -DARM_CLOSED or the like in your closed port. Such a name would make clear what's the issue. At least, only your closed port has this problem. Best regards, Goetz. These should not break the open port if ARM gets defined, or can be fixed easily. --------------------------------------------------------- *** share/vm/c1/c1_LIR.cpp: print[1519] #elif defined(ARM) ==> Use ARM32 as after AARCH64 in if-cascade. *** os/linux/vm/os_linux.cpp: dll_load[1796] #elif (defined ARM) get_summary_cpu_info[2273] #elif defined(ARM) ==> Use ARM32 as after AARCH64 in if-cascade. *** share/vm/opto/matcher.cpp: init_first_stack_mask[558] #ifdef ARM ==> Should be ARM32 (Is under !LP64). *** share/vm/c1/c1_LIR.cpp: validate_type[212] ARM_ONLY(|| kindfield == cpu_register) validate_type[219] ARM_ONLY(|| kindfield == cpu_register) ==> Just an assertion. Will just relax the check if defined in open AARCH64. But maybe should be guarded by __SOFTFP__. [70] #if defined(ARM) || defined(AARCH64) || defined(PPC64) ==> Fine: || *** share/vm/c1/c1_LIR.hpp: [447] #if defined(SPARC) || defined(ARM) || defined(PPC) || defined(AARCH64) [537] #if defined(X86) || defined(ARM) || defined(AARCH64) ==> Fine: || *** share/vm/interpreter/interpreterRuntime.hpp: defined[162] #if defined(IA32) || defined(AMD64) || defined(ARM) *** share/vm/interpreter/interpreterRuntime.cpp: [1358] #if defined(IA32) || defined(AMD64) || defined(ARM) ==> Just defines a method which would be unused, should be fine. These are in code not used in the open AARCH64 port: -------------------------------------------------- *** os/bsd/vm/os_bsd.cpp: [215] #elif defined(ARM) *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: [102] #ifdef ARM *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: [31] #ifdef ARM *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: [102] #ifdef ARM *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: [31] #ifdef ARM *** share/vm/utilities/macros.hpp: [434] #ifdef ARM *** os/bsd/vm/os_bsd.cpp: dll_load[1508] #elif (defined ARM) dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, ALPHA, MIPS, MIPSEL, PARISC, M68K *** os/solaris/vm/os_solaris.cpp: dll_load[1725] #elif (defined ARM) dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, ARM *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: store[164] #if !defined(ARM) && !defined(M68K) store_ptr[171] #if !defined(ARM) && !defined(M68K) add[178] #ifdef ARM add_ptr[190] #ifdef ARM xchg[230] #ifdef ARM xchg_ptr[253] #ifdef ARM cmpxchg[275] #ifdef ARM cmpxchg_ptr[298] #ifdef ARM *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: add[172] #ifdef ARM add_ptr[184] #ifdef ARM xchg[224] #ifdef ARM xchg_ptr[247] #ifdef ARM cmpxchg[269] #ifdef ARM cmpxchg_ptr[292] #ifdef ARM > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 19. Juli 2016 23:59 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Hi Goetz, > > On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > we also have "closed ports", currently HPUX, ia64 and s390. > > (Parisc is gone, puh!). > > We basically patch all the shared changes onto the sources after > > getting them via our licensee channel. > > I think you should fix your closed port not to re-use the names of the > > main openJdk platforms! > > Nobody "owns" a define of AARCH64 or ARM. We did not want to have to > pollute the shared sources with two sets of ifdefs for "64-bit ARM" so > we worked with the Open port to ensure that shared code guarded by > AARCH64 is suitable for both. We also ensured ARM was used to identify > word-size agnostic code and we introduced ARM32 in a handful of places > that needed it. And sometimes we have to be careful and ensure that > ifdef chains check AARCH64 before they check ARM. > > This has all been working quite nicely, as the include guards used, for > example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which are > never > defined at the same time (derived from HOTSPOT_TARGET_CPU_ARCH). But > the > current changes remove those unique defines and, before the HEADER_H > forms were introduced, tried to use simple AARCH64 and ARM as include > guards, and that doesn't work as they are not mutually exclusive. > > So what I'm suggesting is just not getting rid of those defines, but > keeping them so they can be used as include guards (or other conditional > code) when needed, and where the macros are not suitable. > > Thanks, > David > ----- > > > I have no idea what hardware is addressed by your closed ports, > > nor how you merge sources. > > Is there also a port that sets > > -DTARGET_ARCH_arm > > -DARM > > -DARM32 > > ? > > > > To fix this either you define > > #if defined(ARM) && defined(_LP64) > > #define ARM64 > > #endif > > in macros.hpp or you set -DARM64 on the command line. > > Then you replace all > > #ifdef AARCH64 > > by > > #if defined(AARCH64) || defined(ARM64) > > or maybe it suffices altogether f you replace > > #ifdef AARCH64 > > by > > #if defined(AARCH64) || defined(ARM) > > > > For ppc, when we did the port we knew (and that's all we knew) > > that you have a 32-bit port. Therefore we set up these macros > > as on x86, where there is one for the arch (X86) and two for LP64/!LP64 > > (IA32, AMD64). This allowed to separate code for the closed port > > (guarded by PPC32), the open port (PPC64) and shared for both (PPC). > > > > But I don't think it is necessary to do any further changes now, assuming > > my change works for you as I adapted it. So we're all set I guess! > > > > Best regards, > > Goetz. > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Tuesday, July 19, 2016 1:23 PM > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > >>>> workaround is obscure - you have to know that the Open Aarch64 port > >>>> defines AARCH64 but not ARM and so that code is for the Open port > use > >>>> only. There's no issue for the OS defines, but I wonder - just something > >>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>> > >>> Well, I think TARGET_ARCH_xxx always was xxx. > >>> And I'm uneasy that it is no more. How do you handle that? You have to > >>> check every AARCH change by RedHat against your closed port? > >> > >> The sources for the two ports are distinct so the only place we have to > >> have a convention is in shared code that has CPU specific stuff and in > >> the build files. > >> > >> The open Aarch64 port sets (among others): > >> -DTARGET_ARCH_aarch64 > >> -DAARCH64 > >> > >> the closed port sets > >> > >> -DTARGET_ARCH_arm > >> -DARM > >> -DAARCH64 > >> > >> so it is the value of TARGET_ARCH_xxx that distinguishes them. > Whenever > >> you saw TARGET_ARCH_arm in open shared code it is/was referring to > our > >> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 port. > >> > >> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >> > >> We need to keep a clear distinction. Using the combination of AARCH64 > >> and ARM is not so clear. > >> > >> You could easily have similar issues with other port groups - eg ppc64 > >> vs ppc32 vs ppcle. > >> > >> Thanks, > >> David > >> > >>> I don't know about the closed stuff, but aarch came up recently, and > >>> before that it sure was equivalent. And it still is the case for openJDK. > >>> > >>> Below output is grepped out of the make//platform_ files in > >>> jdk8/hotspot, and none of the cpu/arch names are defined twice. > >>> Zero is an exception I guess, as it's no real cpu/arch. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> sysdefs = -DAIX -DPPC64 > >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - > >> DAMD64 > >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - > DIA32 > >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO - > >> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Thanks Goetz. Will get back to you asap if there are any further issues, > >>>> but the incremental changes look okay. > >>>> > >>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I added macros for C headers: > >>>>> CPU_HEADER_H() etc. > >>>>> and fixed the other issues mentioned by David and Coleen in this new > >>>> webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >> newPfmIncl/webrev.03/ > >>>>> > >>>>> I also added comments that AARCH64 and ARM are defined > >>>>> at the same time. > >>>>> > >>>>> Further I edited vmStructs_jvmci.cpp to > >>>>> #if defined(AARCH64) && !defined(ARM) > >>>> > >>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > >>>> workaround is obscure - you have to know that the Open Aarch64 port > >>>> defines AARCH64 but not ARM and so that code is for the Open port > use > >>>> only. There's no issue for the OS defines, but I wonder - just something > >>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> My incremental changes are in this patch: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed > >>>>>>>> in the closed code. > >>>>>>> > >>>>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>>>> > >>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the > ifdef > >> is > >>>> not > >>>>>>> going to work for our closed ports, unless I change that value to > >> match > >>>>>>> the open naming scheme. But that in turn will lead to other > problems > >> as > >>>>>>> we also need that value the way it is currently defined. > >>>>>>> > >>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>> > >>>>>> Sorry but this really does need the CPU_HEADER_H macro. In > general > >> you > >>>>>> can't just replace: > >>>>>> > >>>>>> #ifdef TARGET_ARCH_abc > >>>>>> > >>>>>> with > >>>>>> > >>>>>> #ifdef abc > >>>>>> > >>>>>> because the "abc"'s may not be mutually exclusive. In our case ARM > >> and > >>>>>> AARCH64 are both defined and are both needed. In contrast > >>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to > represent > >> the > >>>>>> architecture in this context. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> > >>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Goetz. > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>> > >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>> dev at openjdk.java.net > >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>> > >>>>>>>>> Hi Goetz, > >>>>>>>>> > >>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> Hi David, > >>>>>>>>>> > >>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>> > >>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that > >>>>>> appends.h > >>>>>>>>>>>>> instead? > >>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only > >> once. > >>>>>>>>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>>>>>>>> similar everywhere. > >>>>>>>>>>> > >>>>>>>>>>> We actually need this as the simple arch names need not be > >>>> mutually > >>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an > if- > >>>> else > >>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>> They should be mutually exclusive, as they are set in > >>>> CompileJvm.gmk > >>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>> > >>>>>>>>> Unfortunately we also have -DARM coming in from the closed > part > >> of > >>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get both > >>>> defined > >>>>>>>>> and try to include two platform files. > >>>>>>>>> > >>>>>>>>> Not sure how to try and resolve this yet. Trying to understand > what > >>>> the > >>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we > >> are > >>>> not > >>>>>>>>> overriding it for our port - which I think is the current problem, > but > >>>>>>>>> changing it may break something else. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>>> > >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>> > >>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>> Hi David, > >>>>>>>>>>>> > >>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>> Barrett > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> Generally looks okay, a couple of clarifications and > comments > >>>>>> below. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>> > >>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>> Yes. > >>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>> the _32/_64 source files in a common arch directory, but I > >> don't > >>>>>>>>>>>>> think > >>>>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I > >>>>>>>>>>>>> haven't had > >>>>>>>>>>>>> the time yet to apply this patch and see what needs to be > >>>> changed > >>>>>> on > >>>>>>>>> the > >>>>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>>>> If I run plain configure, it generates a directory that has the > >>>>>>>>>>>> word size > >>>>>>>>>>>> in it's name: > >>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>> > >>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>> > >>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 header > files if > >> I > >>>>>>>>>>>>> read it > >>>>>>>>>>>>> right ?? So I'll need a common file that dispatches internally > for > >>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>> Yes. > >>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: > >>>>>>>>>>>> stubRoutines > >>>>>>>>>>>> But this was rather small. And there anyways was a common > file > >>>>>>>>>>>> that was included in both. > >>>>>>>>>>>> > >>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind > of > >>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>> > >>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> > >>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>> > >>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>> > >>>>>>>>>>>>> ? :) > >>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>>>>>>>>>>> Actually I think the implementation should be moved to > >>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> > >>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> Not clear why the platform include can simply be elided > here ?? > >>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the > umbrella > >>>> header > >>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>> > >>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>> > >>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>> > >>>>>>>>>>>>> be: > >>>>>>>>>>>>> > >>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> > >>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>> > >>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that > >>>>>> appends.h > >>>>>>>>>>>>> instead? > >>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only > >> once. > >>>>>>>>>>>> So I figured not to do it. But probably I should do it to get is > >>>>>>>>>>>> similar everywhere. > >>>>>>>>>>> > >>>>>>>>>>> We actually need this as the simple arch names need not be > >>>> mutually > >>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an > if- > >>>> else > >>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> David > >>>>>>>>>>> ----- > >>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> > >>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>> > >>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>> #include > >>>>>>>>>>>>> #endif > >>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> #endif > >>>>>>>>>>>>> ? > >>>>>>>>>>>> Fixed. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that > >> coming > >>>>>> from > >>>>>>>>> the > >>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>> I wondered about that, too. Therefore I defined WINDOWS > in > >> the > >>>>>>>>>>>> prototype webrev. Then I saw that our build is defining - > >>>>>> D_WINDOWS > >>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but not in > this > >>>>>>>>>>>> change. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> > >>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>> > >>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>> I just copied the linux_ppc code and removed the unused > >>>>>>>>> implementation. > >>>>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Goetz. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> ----- > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> thanks for this version of the macros, it's working on all > the > >>>>>>>>> platforms > >>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and > >> not > >>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>> command line. This way, parts of the name > construction > >> are > >>>> in > >>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But > >>>>>> constructing > >>>>>>>>>>>>>>>> the search path is also in the makefile, and uses the > very > >>>> same > >>>>>>>>> string > >>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include that > in > >> the > >>>>>>>>> macro, > >>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine with > your > >>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that the > linux=1 > >>>> etc > >>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Any more opinions whether the macros should be > upper > >> case? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > > >>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- > compiler- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> please take into account that these macros are only > >> used > >>>>>> within > >>>>>>>>> 20 > >>>>>>>>>>>>> lines > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to > >>>> understand > >>>>>> is > >>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and > expands to > >>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend days > >>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my current > >>>> progress > >>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is adding > the > >>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >> dev/2016- > >>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed > in > >> that > >>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >> dev/2016- > >>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I think I see what happened to the email thread for > me; it > >>>> looks > >>>>>>>>> like > >>>>>>>>>>> one > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but > not > >>>>>> hotspot- > >>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this > morning. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only > >>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until > the > >>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ > ---- > >> --- > >>>> --- > >>>>>> -- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines > >> that > >>>>>> spoil > >>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, > >>>> sparc=1. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> This issue can be dodged by making the leading > >> underscore > >>>>>> part > >>>>>>>>> of > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>> 67 - > DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >> \ > >>>>>>>>>>>>>>>>> 68 - > >>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>> \ > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> If some future build system wants brackets instead of > >>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, > but > >>>>>>>>>>>>>>>>> that's > >>>>>>>>> true > >>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that underscore > >>>>>> followed > >>>>>>>>> by a > >>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern > for > >>>> C/C++. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for > the > >>>> macro > >>>>>>>>>>> names. > >>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ > ---- > >> --- > >>>> --- > >>>>>> -- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> From david.holmes at oracle.com Wed Jul 20 09:12:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 19:12:40 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> Message-ID: <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> Hi Goetz, On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > Hi David, > > that's great what you are saying and just the design I would expect! >> We did not want to have to >> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >> we worked with the Open port to ensure that shared code guarded by >> AARCH64 is suitable for both. We also ensured ARM was used to identify >> word-size agnostic code and we introduced ARM32 in a handful of places >> that needed it. And sometimes we have to be careful and ensure that >> ifdef chains check AARCH64 before they check ARM. > > I think as a consequence the open AARCH port should define ARM, too. I would not want to do this and certainly not as part of this change. If/when the Aarch32 port arrives we may have to revisit this, but not right now, please. > I checked the occurrences and only see three places where this would have > an effect and would have to be fixed somehow: > > *** share/vm/jvmci/vmStructs_jvmci.cpp: > [610] #if defined(AARCH64) && !defined(ARM) > ==> Would this break the closed port if defined? Yes - it refers to specific piece of code in the open aarch64 sources. > (This is the only place where TARGET_ARCH_aarch64 was used) > > *** share/vm/c1/c1_LIRGenerator.cpp: > load_item_force[253] #if !defined(ARM) && !defined(E500V2) > ==> Would this break the open port if defined? > > *** share/vm/c1/c1_Runtime1.cpp: > [1154] #ifdef ARM > ==> Would this break the open port if defined? I don't think the open port has C1 so it would ignore the above files anyway. > All the cases below are pointless. > >> So what I'm suggesting is just not getting rid of those defines, but >> keeping them so they can be used as include guards (or other conditional >> code) when needed, and where the macros are not suitable. > I think it's quite misleading to have two defines that are 99% equivalent. > If we really need a special case here, you should define -DARM_CLOSED > or the like in your closed port. Such a name would make clear what's the > issue. At least, only your closed port has this problem. I really do not want to make any changes to this - ignoring the include macro changes everything we have is working perfectly fine just the way the defines are. So I don't want to see this change potentially break that through incidental changes. I do not see having the following is a big issue: -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and TARGET_ARCH_arm to mean whatever the owners of that define intend it to mean. It certainly is a lot better than interpreting what the combinations of AARCH64 and ARM mean. Keeping this removes the need to perform some of the changes as noted above. I'm preparing the review of the internal changes we need to accompany this. Thanks, David ----- > > Best regards, > Goetz. > > > > These should not break the open port if ARM gets defined, or can be fixed easily. > --------------------------------------------------------- > > *** share/vm/c1/c1_LIR.cpp: > print[1519] #elif defined(ARM) > ==> Use ARM32 as after AARCH64 in if-cascade. > > *** os/linux/vm/os_linux.cpp: > dll_load[1796] #elif (defined ARM) > get_summary_cpu_info[2273] #elif defined(ARM) > ==> Use ARM32 as after AARCH64 in if-cascade. > > *** share/vm/opto/matcher.cpp: > init_first_stack_mask[558] #ifdef ARM > ==> Should be ARM32 (Is under !LP64). > > *** share/vm/c1/c1_LIR.cpp: > validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > ==> Just an assertion. Will just relax the check if defined in open AARCH64. > But maybe should be guarded by __SOFTFP__. > [70] #if defined(ARM) || defined(AARCH64) || defined(PPC64) > ==> Fine: || > > *** share/vm/c1/c1_LIR.hpp: > [447] #if defined(SPARC) || defined(ARM) || defined(PPC) || defined(AARCH64) > [537] #if defined(X86) || defined(ARM) || defined(AARCH64) > ==> Fine: || > > *** share/vm/interpreter/interpreterRuntime.hpp: > defined[162] #if defined(IA32) || defined(AMD64) || defined(ARM) > *** share/vm/interpreter/interpreterRuntime.cpp: > [1358] #if defined(IA32) || defined(AMD64) || defined(ARM) > ==> Just defines a method which would be unused, should be fine. > > > These are in code not used in the open AARCH64 port: > -------------------------------------------------- > > *** os/bsd/vm/os_bsd.cpp: > [215] #elif defined(ARM) > > *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > [102] #ifdef ARM > > *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > [31] #ifdef ARM > > *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > [102] #ifdef ARM > > *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > [31] #ifdef ARM > > *** share/vm/utilities/macros.hpp: > [434] #ifdef ARM > > *** os/bsd/vm/os_bsd.cpp: > dll_load[1508] #elif (defined ARM) > dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > > *** os/solaris/vm/os_solaris.cpp: > dll_load[1725] #elif (defined ARM) > dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, ARM > > *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > store[164] #if !defined(ARM) && !defined(M68K) > store_ptr[171] #if !defined(ARM) && !defined(M68K) > add[178] #ifdef ARM > add_ptr[190] #ifdef ARM > xchg[230] #ifdef ARM > xchg_ptr[253] #ifdef ARM > cmpxchg[275] #ifdef ARM > cmpxchg_ptr[298] #ifdef ARM > > *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > add[172] #ifdef ARM > add_ptr[184] #ifdef ARM > xchg[224] #ifdef ARM > xchg_ptr[247] #ifdef ARM > cmpxchg[269] #ifdef ARM > cmpxchg_ptr[292] #ifdef ARM > > > > > > > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 19. Juli 2016 23:59 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> Hi Goetz, >> >> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> we also have "closed ports", currently HPUX, ia64 and s390. >>> (Parisc is gone, puh!). >>> We basically patch all the shared changes onto the sources after >>> getting them via our licensee channel. >>> I think you should fix your closed port not to re-use the names of the >>> main openJdk platforms! >> >> Nobody "owns" a define of AARCH64 or ARM. We did not want to have to >> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >> we worked with the Open port to ensure that shared code guarded by >> AARCH64 is suitable for both. We also ensured ARM was used to identify >> word-size agnostic code and we introduced ARM32 in a handful of places >> that needed it. And sometimes we have to be careful and ensure that >> ifdef chains check AARCH64 before they check ARM. >> >> This has all been working quite nicely, as the include guards used, for >> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which are >> never >> defined at the same time (derived from HOTSPOT_TARGET_CPU_ARCH). But >> the >> current changes remove those unique defines and, before the HEADER_H >> forms were introduced, tried to use simple AARCH64 and ARM as include >> guards, and that doesn't work as they are not mutually exclusive. >> >> So what I'm suggesting is just not getting rid of those defines, but >> keeping them so they can be used as include guards (or other conditional >> code) when needed, and where the macros are not suitable. >> >> Thanks, >> David >> ----- >> >>> I have no idea what hardware is addressed by your closed ports, >>> nor how you merge sources. >>> Is there also a port that sets >>> -DTARGET_ARCH_arm >>> -DARM >>> -DARM32 >>> ? >>> >>> To fix this either you define >>> #if defined(ARM) && defined(_LP64) >>> #define ARM64 >>> #endif >>> in macros.hpp or you set -DARM64 on the command line. >>> Then you replace all >>> #ifdef AARCH64 >>> by >>> #if defined(AARCH64) || defined(ARM64) >>> or maybe it suffices altogether f you replace >>> #ifdef AARCH64 >>> by >>> #if defined(AARCH64) || defined(ARM) >>> >>> For ppc, when we did the port we knew (and that's all we knew) >>> that you have a 32-bit port. Therefore we set up these macros >>> as on x86, where there is one for the arch (X86) and two for LP64/!LP64 >>> (IA32, AMD64). This allowed to separate code for the closed port >>> (guarded by PPC32), the open port (PPC64) and shared for both (PPC). >>> >>> But I don't think it is necessary to do any further changes now, assuming >>> my change works for you as I adapted it. So we're all set I guess! >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >>>>>> workaround is obscure - you have to know that the Open Aarch64 port >>>>>> defines AARCH64 but not ARM and so that code is for the Open port >> use >>>>>> only. There's no issue for the OS defines, but I wonder - just something >>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>> >>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>> And I'm uneasy that it is no more. How do you handle that? You have to >>>>> check every AARCH change by RedHat against your closed port? >>>> >>>> The sources for the two ports are distinct so the only place we have to >>>> have a convention is in shared code that has CPU specific stuff and in >>>> the build files. >>>> >>>> The open Aarch64 port sets (among others): >>>> -DTARGET_ARCH_aarch64 >>>> -DAARCH64 >>>> >>>> the closed port sets >>>> >>>> -DTARGET_ARCH_arm >>>> -DARM >>>> -DAARCH64 >>>> >>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >> Whenever >>>> you saw TARGET_ARCH_arm in open shared code it is/was referring to >> our >>>> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 port. >>>> >>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>> >>>> We need to keep a clear distinction. Using the combination of AARCH64 >>>> and ARM is not so clear. >>>> >>>> You could easily have similar issues with other port groups - eg ppc64 >>>> vs ppc32 vs ppcle. >>>> >>>> Thanks, >>>> David >>>> >>>>> I don't know about the closed stuff, but aarch came up recently, and >>>>> before that it sure was equivalent. And it still is the case for openJDK. >>>>> >>>>> Below output is grepped out of the make//platform_ files in >>>>> jdk8/hotspot, and none of the cpu/arch names are defined twice. >>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> sysdefs = -DAIX -DPPC64 >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - >>>> DAMD64 >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - >> DIA32 >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Thanks Goetz. Will get back to you asap if there are any further issues, >>>>>> but the incremental changes look okay. >>>>>> >>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I added macros for C headers: >>>>>>> CPU_HEADER_H() etc. >>>>>>> and fixed the other issues mentioned by David and Coleen in this new >>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>> newPfmIncl/webrev.03/ >>>>>>> >>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>> at the same time. >>>>>>> >>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>> >>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >>>>>> workaround is obscure - you have to know that the Open Aarch64 port >>>>>> defines AARCH64 but not ARM and so that code is for the Open port >> use >>>>>> only. There's no issue for the OS defines, but I wonder - just something >>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> My incremental changes are in this patch: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed >>>>>>>>>> in the closed code. >>>>>>>>> >>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>>>>>> >>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the >> ifdef >>>> is >>>>>> not >>>>>>>>> going to work for our closed ports, unless I change that value to >>>> match >>>>>>>>> the open naming scheme. But that in turn will lead to other >> problems >>>> as >>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>> >>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>> >>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. In >> general >>>> you >>>>>>>> can't just replace: >>>>>>>> >>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>> >>>>>>>> with >>>>>>>> >>>>>>>> #ifdef abc >>>>>>>> >>>>>>>> because the "abc"'s may not be mutually exclusive. In our case ARM >>>> and >>>>>>>> AARCH64 are both defined and are both needed. In contrast >>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to >> represent >>>> the >>>>>>>> architecture in this context. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>>> >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >>>>>>>> appends.h >>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only >>>> once. >>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>> >>>>>>>>>>>>> We actually need this as the simple arch names need not be >>>>>> mutually >>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an >> if- >>>>>> else >>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>> CompileJvm.gmk >>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>> >>>>>>>>>>> Unfortunately we also have -DARM coming in from the closed >> part >>>> of >>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get both >>>>>> defined >>>>>>>>>>> and try to include two platform files. >>>>>>>>>>> >>>>>>>>>>> Not sure how to try and resolve this yet. Trying to understand >> what >>>>>> the >>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as we >>>> are >>>>>> not >>>>>>>>>>> overriding it for our port - which I think is the current problem, >> but >>>>>>>>>>> changing it may break something else. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>> >>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and >> comments >>>>>>>> below. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>> the _32/_64 source files in a common arch directory, but I >>>> don't >>>>>>>>>>>>>>> think >>>>>>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I >>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>> the time yet to apply this patch and see what needs to be >>>>>> changed >>>>>>>> on >>>>>>>>>>> the >>>>>>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>>>>>> If I run plain configure, it generates a directory that has the >>>>>>>>>>>>>> word size >>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>> >>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 header >> files if >>>> I >>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches internally >> for >>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>> But this was rather small. And there anyways was a common >> file >>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this kind >> of >>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>>>>>>>> Actually I think the implementation should be moved to >>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not clear why the platform include can simply be elided >> here ?? >>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the >> umbrella >>>>>> header >>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, that >>>>>>>> appends.h >>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used only >>>> once. >>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to get is >>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>> >>>>>>>>>>>>> We actually need this as the simple arch names need not be >>>>>> mutually >>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be an >> if- >>>>>> else >>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>> ? >>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that >>>> coming >>>>>>>> from >>>>>>>>>>> the >>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>> I wondered about that, too. Therefore I defined WINDOWS >> in >>>> the >>>>>>>>>>>>>> prototype webrev. Then I saw that our build is defining - >>>>>>>> D_WINDOWS >>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but not in >> this >>>>>>>>>>>>>> change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>> I just copied the linux_ppc code and removed the unused >>>>>>>>>>> implementation. >>>>>>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's working on all >> the >>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros and >>>> not >>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>> command line. This way, parts of the name >> construction >>>> are >>>>>> in >>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But >>>>>>>> constructing >>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses the >> very >>>>>> same >>>>>>>>>>> string >>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include that >> in >>>> the >>>>>>>>>>> macro, >>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine with >> your >>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that the >> linux=1 >>>>>> etc >>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Any more opinions whether the macros should be >> upper >>>> case? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> >>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- >> compiler- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> please take into account that these macros are only >>>> used >>>>>>>> within >>>>>>>>>>> 20 >>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to >>>>>> understand >>>>>>>> is >>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and >> expands to >>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend days >>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my current >>>>>> progress >>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is adding >> the >>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>> dev/2016- >>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker proposed >> in >>>> that >>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>> dev/2016- >>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think I see what happened to the email thread for >> me; it >>>>>> looks >>>>>>>>>>> like >>>>>>>>>>>>> one >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but >> not >>>>>>>> hotspot- >>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this >> morning. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only >>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait until >> the >>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >> ---- >>>> --- >>>>>> --- >>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing #defines >>>> that >>>>>>>> spoil >>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: linux=1, >>>>>> sparc=1. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This issue can be dodged by making the leading >>>> underscore >>>>>>>> part >>>>>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>> 67 - >> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>> \ >>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If some future build system wants brackets instead of >>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are defined, >> but >>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>> true >>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that underscore >>>>>>>> followed >>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern >> for >>>>>> C/C++. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for >> the >>>>>> macro >>>>>>>>>>>>> names. >>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >> ---- >>>> --- >>>>>> --- >>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Wed Jul 20 09:21:41 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jul 2016 09:21:41 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> Message-ID: Hi David, OK, to get this through I will add -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) and revert this one and only place it needs to be used in the vmStructs_jvmci.cpp. For the records, openJdk aarch64 has a C1 port. And yes, such cleanups should not be in this change. Thanks for doing the closed changes! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 20. Juli 2016 11:13 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > Hi Goetz, > > On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > that's great what you are saying and just the design I would expect! > >> We did not want to have to > >> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so > >> we worked with the Open port to ensure that shared code guarded by > >> AARCH64 is suitable for both. We also ensured ARM was used to identify > >> word-size agnostic code and we introduced ARM32 in a handful of places > >> that needed it. And sometimes we have to be careful and ensure that > >> ifdef chains check AARCH64 before they check ARM. > > > > I think as a consequence the open AARCH port should define ARM, too. > > I would not want to do this and certainly not as part of this change. > If/when the Aarch32 port arrives we may have to revisit this, but not > right now, please. > > > I checked the occurrences and only see three places where this would have > > an effect and would have to be fixed somehow: > > > > *** share/vm/jvmci/vmStructs_jvmci.cpp: > > [610] #if defined(AARCH64) && !defined(ARM) > > ==> Would this break the closed port if defined? > > Yes - it refers to specific piece of code in the open aarch64 sources. > > > (This is the only place where TARGET_ARCH_aarch64 was used) > > > > *** share/vm/c1/c1_LIRGenerator.cpp: > > load_item_force[253] #if !defined(ARM) && !defined(E500V2) > > ==> Would this break the open port if defined? > > > > *** share/vm/c1/c1_Runtime1.cpp: > > [1154] #ifdef ARM > > ==> Would this break the open port if defined? > > I don't think the open port has C1 so it would ignore the above files > anyway. > > > All the cases below are pointless. > > > >> So what I'm suggesting is just not getting rid of those defines, but > >> keeping them so they can be used as include guards (or other conditional > >> code) when needed, and where the macros are not suitable. > > I think it's quite misleading to have two defines that are 99% equivalent. > > If we really need a special case here, you should define -DARM_CLOSED > > or the like in your closed port. Such a name would make clear what's the > > issue. At least, only your closed port has this problem. > > I really do not want to make any changes to this - ignoring the include > macro changes everything we have is working perfectly fine just the way > the defines are. So I don't want to see this change potentially break > that through incidental changes. > > I do not see having the following is a big issue: > > -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > > It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and > TARGET_ARCH_arm to mean whatever the owners of that define intend it to > mean. It certainly is a lot better than interpreting what the > combinations of AARCH64 and ARM mean. Keeping this removes the need to > perform some of the changes as noted above. > > I'm preparing the review of the internal changes we need to accompany this. > > Thanks, > David > ----- > > > > > Best regards, > > Goetz. > > > > > > > > These should not break the open port if ARM gets defined, or can be fixed > easily. > > --------------------------------------------------------- > > > > *** share/vm/c1/c1_LIR.cpp: > > print[1519] #elif defined(ARM) > > ==> Use ARM32 as after AARCH64 in if-cascade. > > > > *** os/linux/vm/os_linux.cpp: > > dll_load[1796] #elif (defined ARM) > > get_summary_cpu_info[2273] #elif defined(ARM) > > ==> Use ARM32 as after AARCH64 in if-cascade. > > > > *** share/vm/opto/matcher.cpp: > > init_first_stack_mask[558] #ifdef ARM > > ==> Should be ARM32 (Is under !LP64). > > > > *** share/vm/c1/c1_LIR.cpp: > > validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > > validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > > ==> Just an assertion. Will just relax the check if defined in open AARCH64. > > But maybe should be guarded by __SOFTFP__. > > [70] #if defined(ARM) || defined(AARCH64) || > defined(PPC64) > > ==> Fine: || > > > > *** share/vm/c1/c1_LIR.hpp: > > [447] #if defined(SPARC) || defined(ARM) || > defined(PPC) || defined(AARCH64) > > [537] #if defined(X86) || defined(ARM) || > defined(AARCH64) > > ==> Fine: || > > > > *** share/vm/interpreter/interpreterRuntime.hpp: > > defined[162] #if defined(IA32) || defined(AMD64) || > defined(ARM) > > *** share/vm/interpreter/interpreterRuntime.cpp: > > [1358] #if defined(IA32) || defined(AMD64) || > defined(ARM) > > ==> Just defines a method which would be unused, should be fine. > > > > > > These are in code not used in the open AARCH64 port: > > -------------------------------------------------- > > > > *** os/bsd/vm/os_bsd.cpp: > > [215] #elif defined(ARM) > > > > *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > > [102] #ifdef ARM > > > > *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > > [31] #ifdef ARM > > > > *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > > [102] #ifdef ARM > > > > *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > > [31] #ifdef ARM > > > > *** share/vm/utilities/macros.hpp: > > [434] #ifdef ARM > > > > *** os/bsd/vm/os_bsd.cpp: > > dll_load[1508] #elif (defined ARM) > > dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, > S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > > > > *** os/solaris/vm/os_solaris.cpp: > > dll_load[1725] #elif (defined ARM) > > dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, > ARM > > > > *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > > store[164] #if !defined(ARM) && !defined(M68K) > > store_ptr[171] #if !defined(ARM) && !defined(M68K) > > add[178] #ifdef ARM > > add_ptr[190] #ifdef ARM > > xchg[230] #ifdef ARM > > xchg_ptr[253] #ifdef ARM > > cmpxchg[275] #ifdef ARM > > cmpxchg_ptr[298] #ifdef ARM > > > > *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > > add[172] #ifdef ARM > > add_ptr[184] #ifdef ARM > > xchg[224] #ifdef ARM > > xchg_ptr[247] #ifdef ARM > > cmpxchg[269] #ifdef ARM > > cmpxchg_ptr[292] #ifdef ARM > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Dienstag, 19. Juli 2016 23:59 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> Hi Goetz, > >> > >> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> we also have "closed ports", currently HPUX, ia64 and s390. > >>> (Parisc is gone, puh!). > >>> We basically patch all the shared changes onto the sources after > >>> getting them via our licensee channel. > >>> I think you should fix your closed port not to re-use the names of the > >>> main openJdk platforms! > >> > >> Nobody "owns" a define of AARCH64 or ARM. We did not want to have to > >> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so > >> we worked with the Open port to ensure that shared code guarded by > >> AARCH64 is suitable for both. We also ensured ARM was used to identify > >> word-size agnostic code and we introduced ARM32 in a handful of places > >> that needed it. And sometimes we have to be careful and ensure that > >> ifdef chains check AARCH64 before they check ARM. > >> > >> This has all been working quite nicely, as the include guards used, for > >> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which are > >> never > >> defined at the same time (derived from HOTSPOT_TARGET_CPU_ARCH). > But > >> the > >> current changes remove those unique defines and, before the HEADER_H > >> forms were introduced, tried to use simple AARCH64 and ARM as include > >> guards, and that doesn't work as they are not mutually exclusive. > >> > >> So what I'm suggesting is just not getting rid of those defines, but > >> keeping them so they can be used as include guards (or other conditional > >> code) when needed, and where the macros are not suitable. > >> > >> Thanks, > >> David > >> ----- > >> > >>> I have no idea what hardware is addressed by your closed ports, > >>> nor how you merge sources. > >>> Is there also a port that sets > >>> -DTARGET_ARCH_arm > >>> -DARM > >>> -DARM32 > >>> ? > >>> > >>> To fix this either you define > >>> #if defined(ARM) && defined(_LP64) > >>> #define ARM64 > >>> #endif > >>> in macros.hpp or you set -DARM64 on the command line. > >>> Then you replace all > >>> #ifdef AARCH64 > >>> by > >>> #if defined(AARCH64) || defined(ARM64) > >>> or maybe it suffices altogether f you replace > >>> #ifdef AARCH64 > >>> by > >>> #if defined(AARCH64) || defined(ARM) > >>> > >>> For ppc, when we did the port we knew (and that's all we knew) > >>> that you have a 32-bit port. Therefore we set up these macros > >>> as on x86, where there is one for the arch (X86) and two for LP64/!LP64 > >>> (IA32, AMD64). This allowed to separate code for the closed port > >>> (guarded by PPC32), the open port (PPC64) and shared for both (PPC). > >>> > >>> But I don't think it is necessary to do any further changes now, assuming > >>> my change works for you as I adapted it. So we're all set I guess! > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > >>>>>> workaround is obscure - you have to know that the Open Aarch64 > port > >>>>>> defines AARCH64 but not ARM and so that code is for the Open port > >> use > >>>>>> only. There's no issue for the OS defines, but I wonder - just > something > >>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>> > >>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>> And I'm uneasy that it is no more. How do you handle that? You have > to > >>>>> check every AARCH change by RedHat against your closed port? > >>>> > >>>> The sources for the two ports are distinct so the only place we have to > >>>> have a convention is in shared code that has CPU specific stuff and in > >>>> the build files. > >>>> > >>>> The open Aarch64 port sets (among others): > >>>> -DTARGET_ARCH_aarch64 > >>>> -DAARCH64 > >>>> > >>>> the closed port sets > >>>> > >>>> -DTARGET_ARCH_arm > >>>> -DARM > >>>> -DAARCH64 > >>>> > >>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. > >> Whenever > >>>> you saw TARGET_ARCH_arm in open shared code it is/was referring to > >> our > >>>> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 > port. > >>>> > >>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >>>> > >>>> We need to keep a clear distinction. Using the combination of AARCH64 > >>>> and ARM is not so clear. > >>>> > >>>> You could easily have similar issues with other port groups - eg ppc64 > >>>> vs ppc32 vs ppcle. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> I don't know about the closed stuff, but aarch came up recently, and > >>>>> before that it sure was equivalent. And it still is the case for openJDK. > >>>>> > >>>>> Below output is grepped out of the make//platform_ files > in > >>>>> jdk8/hotspot, and none of the cpu/arch names are defined twice. > >>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> sysdefs = -DAIX -DPPC64 > >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - > >>>> DAMD64 > >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - > >> DIA32 > >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - > DZERO - > >>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> Thanks Goetz. Will get back to you asap if there are any further > issues, > >>>>>> but the incremental changes look okay. > >>>>>> > >>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I added macros for C headers: > >>>>>>> CPU_HEADER_H() etc. > >>>>>>> and fixed the other issues mentioned by David and Coleen in this > new > >>>>>> webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>> newPfmIncl/webrev.03/ > >>>>>>> > >>>>>>> I also added comments that AARCH64 and ARM are defined > >>>>>>> at the same time. > >>>>>>> > >>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>> > >>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of > >>>>>> workaround is obscure - you have to know that the Open Aarch64 > port > >>>>>> defines AARCH64 but not ARM and so that code is for the Open port > >> use > >>>>>> only. There's no issue for the OS defines, but I wonder - just > something > >>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> My incremental changes are in this patch: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> Hi Goetz, > >>>>>>>> > >>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> Hi David, > >>>>>>>>>> > >>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed > >>>>>>>>>> in the closed code. > >>>>>>>>> > >>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>>>>>> > >>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the > >> ifdef > >>>> is > >>>>>> not > >>>>>>>>> going to work for our closed ports, unless I change that value to > >>>> match > >>>>>>>>> the open naming scheme. But that in turn will lead to other > >> problems > >>>> as > >>>>>>>>> we also need that value the way it is currently defined. > >>>>>>>>> > >>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>> > >>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. In > >> general > >>>> you > >>>>>>>> can't just replace: > >>>>>>>> > >>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>> > >>>>>>>> with > >>>>>>>> > >>>>>>>> #ifdef abc > >>>>>>>> > >>>>>>>> because the "abc"'s may not be mutually exclusive. In our case > ARM > >>>> and > >>>>>>>> AARCH64 are both defined and are both needed. In contrast > >>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to > >> represent > >>>> the > >>>>>>>> architecture in this context. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>>> > >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>> > >>>>>>>>>>> Hi Goetz, > >>>>>>>>>>> > >>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>> Hi David, > >>>>>>>>>>>> > >>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, > that > >>>>>>>> appends.h > >>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used > only > >>>> once. > >>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to get > is > >>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We actually need this as the simple arch names need not > be > >>>>>> mutually > >>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be > an > >> if- > >>>>>> else > >>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>> They should be mutually exclusive, as they are set in > >>>>>> CompileJvm.gmk > >>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>> > >>>>>>>>>>> Unfortunately we also have -DARM coming in from the closed > >> part > >>>> of > >>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get > both > >>>>>> defined > >>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>> > >>>>>>>>>>> Not sure how to try and resolve this yet. Trying to understand > >> what > >>>>>> the > >>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as > we > >>>> are > >>>>>> not > >>>>>>>>>>> overriding it for our port - which I think is the current problem, > >> but > >>>>>>>>>>> changing it may break something else. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> David > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Goetz > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>> Barrett > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > >> Kim > >>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and > >> comments > >>>>>>>> below. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>> the _32/_64 source files in a common arch directory, but > I > >>>> don't > >>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I > >>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>> the time yet to apply this patch and see what needs to > be > >>>>>> changed > >>>>>>>> on > >>>>>>>>>>> the > >>>>>>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>>>>>> If I run plain configure, it generates a directory that has > the > >>>>>>>>>>>>>> word size > >>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 header > >> files if > >>>> I > >>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches > internally > >> for > >>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: > >>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>> But this was rather small. And there anyways was a > common > >> file > >>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this > kind > >> of > >>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>>>>>>>>>>>>> Actually I think the implementation should be moved to > >>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Not clear why the platform include can simply be elided > >> here ?? > >>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the > >> umbrella > >>>>>> header > >>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, > that > >>>>>>>> appends.h > >>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used > only > >>>> once. > >>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to get > is > >>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We actually need this as the simple arch names need not > be > >>>>>> mutually > >>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be > an > >> if- > >>>>>> else > >>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> ----- > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that > >>>> coming > >>>>>>>> from > >>>>>>>>>>> the > >>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>> I wondered about that, too. Therefore I defined > WINDOWS > >> in > >>>> the > >>>>>>>>>>>>>> prototype webrev. Then I saw that our build is defining - > >>>>>>>> D_WINDOWS > >>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but not > in > >> this > >>>>>>>>>>>>>> change. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>> I just copied the linux_ppc code and removed the unused > >>>>>>>>>>> implementation. > >>>>>>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's working on > all > >> the > >>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros > and > >>>> not > >>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>> command line. This way, parts of the name > >> construction > >>>> are > >>>>>> in > >>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But > >>>>>>>> constructing > >>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses the > >> very > >>>>>> same > >>>>>>>>>>> string > >>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include > that > >> in > >>>> the > >>>>>>>>>>> macro, > >>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine > with > >> your > >>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that the > >> linux=1 > >>>>>> etc > >>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Any more opinions whether the macros should be > >> upper > >>>> case? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> > >>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- > >> compiler- > >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> please take into account that these macros are > only > >>>> used > >>>>>>>> within > >>>>>>>>>>> 20 > >>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to > >>>>>> understand > >>>>>>>> is > >>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and > >> expands to > >>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend > days > >>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my > current > >>>>>> progress > >>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is > adding > >> the > >>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>> dev/2016- > >>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker > proposed > >> in > >>>> that > >>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>> dev/2016- > >>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I think I see what happened to the email thread for > >> me; it > >>>>>> looks > >>>>>>>>>>> like > >>>>>>>>>>>>> one > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but > >> not > >>>>>>>> hotspot- > >>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this > >> morning. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only > >>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait > until > >> the > >>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --------------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> --- > >>>>>>>> -- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing > #defines > >>>> that > >>>>>>>> spoil > >>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: > linux=1, > >>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> This issue can be dodged by making the leading > >>>> underscore > >>>>>>>> part > >>>>>>>>>>> of > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>> 67 - > >> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>> \ > >>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> If some future build system wants brackets instead > of > >>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are > defined, > >> but > >>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that > underscore > >>>>>>>> followed > >>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern > >> for > >>>>>> C/C++. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for > >> the > >>>>>> macro > >>>>>>>>>>>>> names. > >>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --------------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> --- > >>>>>>>> -- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> From david.holmes at oracle.com Wed Jul 20 10:04:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 20:04:36 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> Message-ID: <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > Hi David, > > OK, to get this through I will add > -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > and revert this one and only place it needs to be used in the vmStructs_jvmci.cpp. Thanks. > For the records, openJdk aarch64 has a C1 port. And yes, such cleanups should > not be in this change. I did not know they had a 64-bit C1 - interesting. > > Thanks for doing the closed changes! You're welcome. Cheers, David > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. Juli 2016 11:13 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> Hi Goetz, >> >> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> that's great what you are saying and just the design I would expect! >>>> We did not want to have to >>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >>>> we worked with the Open port to ensure that shared code guarded by >>>> AARCH64 is suitable for both. We also ensured ARM was used to identify >>>> word-size agnostic code and we introduced ARM32 in a handful of places >>>> that needed it. And sometimes we have to be careful and ensure that >>>> ifdef chains check AARCH64 before they check ARM. >>> >>> I think as a consequence the open AARCH port should define ARM, too. >> >> I would not want to do this and certainly not as part of this change. >> If/when the Aarch32 port arrives we may have to revisit this, but not >> right now, please. >> >>> I checked the occurrences and only see three places where this would have >>> an effect and would have to be fixed somehow: >>> >>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>> [610] #if defined(AARCH64) && !defined(ARM) >>> ==> Would this break the closed port if defined? >> >> Yes - it refers to specific piece of code in the open aarch64 sources. >> >>> (This is the only place where TARGET_ARCH_aarch64 was used) >>> >>> *** share/vm/c1/c1_LIRGenerator.cpp: >>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) >>> ==> Would this break the open port if defined? >>> >>> *** share/vm/c1/c1_Runtime1.cpp: >>> [1154] #ifdef ARM >>> ==> Would this break the open port if defined? >> >> I don't think the open port has C1 so it would ignore the above files >> anyway. >> >>> All the cases below are pointless. >>> >>>> So what I'm suggesting is just not getting rid of those defines, but >>>> keeping them so they can be used as include guards (or other conditional >>>> code) when needed, and where the macros are not suitable. >>> I think it's quite misleading to have two defines that are 99% equivalent. >>> If we really need a special case here, you should define -DARM_CLOSED >>> or the like in your closed port. Such a name would make clear what's the >>> issue. At least, only your closed port has this problem. >> >> I really do not want to make any changes to this - ignoring the include >> macro changes everything we have is working perfectly fine just the way >> the defines are. So I don't want to see this change potentially break >> that through incidental changes. >> >> I do not see having the following is a big issue: >> >> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >> >> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >> TARGET_ARCH_arm to mean whatever the owners of that define intend it to >> mean. It certainly is a lot better than interpreting what the >> combinations of AARCH64 and ARM mean. Keeping this removes the need to >> perform some of the changes as noted above. >> >> I'm preparing the review of the internal changes we need to accompany this. >> >> Thanks, >> David >> ----- >> >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> These should not break the open port if ARM gets defined, or can be fixed >> easily. >>> --------------------------------------------------------- >>> >>> *** share/vm/c1/c1_LIR.cpp: >>> print[1519] #elif defined(ARM) >>> ==> Use ARM32 as after AARCH64 in if-cascade. >>> >>> *** os/linux/vm/os_linux.cpp: >>> dll_load[1796] #elif (defined ARM) >>> get_summary_cpu_info[2273] #elif defined(ARM) >>> ==> Use ARM32 as after AARCH64 in if-cascade. >>> >>> *** share/vm/opto/matcher.cpp: >>> init_first_stack_mask[558] #ifdef ARM >>> ==> Should be ARM32 (Is under !LP64). >>> >>> *** share/vm/c1/c1_LIR.cpp: >>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) >>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) >>> ==> Just an assertion. Will just relax the check if defined in open AARCH64. >>> But maybe should be guarded by __SOFTFP__. >>> [70] #if defined(ARM) || defined(AARCH64) || >> defined(PPC64) >>> ==> Fine: || >>> >>> *** share/vm/c1/c1_LIR.hpp: >>> [447] #if defined(SPARC) || defined(ARM) || >> defined(PPC) || defined(AARCH64) >>> [537] #if defined(X86) || defined(ARM) || >> defined(AARCH64) >>> ==> Fine: || >>> >>> *** share/vm/interpreter/interpreterRuntime.hpp: >>> defined[162] #if defined(IA32) || defined(AMD64) || >> defined(ARM) >>> *** share/vm/interpreter/interpreterRuntime.cpp: >>> [1358] #if defined(IA32) || defined(AMD64) || >> defined(ARM) >>> ==> Just defines a method which would be unused, should be fine. >>> >>> >>> These are in code not used in the open AARCH64 port: >>> -------------------------------------------------- >>> >>> *** os/bsd/vm/os_bsd.cpp: >>> [215] #elif defined(ARM) >>> >>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>> [102] #ifdef ARM >>> >>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>> [31] #ifdef ARM >>> >>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>> [102] #ifdef ARM >>> >>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>> [31] #ifdef ARM >>> >>> *** share/vm/utilities/macros.hpp: >>> [434] #ifdef ARM >>> >>> *** os/bsd/vm/os_bsd.cpp: >>> dll_load[1508] #elif (defined ARM) >>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, >> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>> >>> *** os/solaris/vm/os_solaris.cpp: >>> dll_load[1725] #elif (defined ARM) >>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, >> ARM >>> >>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>> store[164] #if !defined(ARM) && !defined(M68K) >>> store_ptr[171] #if !defined(ARM) && !defined(M68K) >>> add[178] #ifdef ARM >>> add_ptr[190] #ifdef ARM >>> xchg[230] #ifdef ARM >>> xchg_ptr[253] #ifdef ARM >>> cmpxchg[275] #ifdef ARM >>> cmpxchg_ptr[298] #ifdef ARM >>> >>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>> add[172] #ifdef ARM >>> add_ptr[184] #ifdef ARM >>> xchg[224] #ifdef ARM >>> xchg_ptr[247] #ifdef ARM >>> cmpxchg[269] #ifdef ARM >>> cmpxchg_ptr[292] #ifdef ARM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> Hi Goetz, >>>> >>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>> (Parisc is gone, puh!). >>>>> We basically patch all the shared changes onto the sources after >>>>> getting them via our licensee channel. >>>>> I think you should fix your closed port not to re-use the names of the >>>>> main openJdk platforms! >>>> >>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to have to >>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >>>> we worked with the Open port to ensure that shared code guarded by >>>> AARCH64 is suitable for both. We also ensured ARM was used to identify >>>> word-size agnostic code and we introduced ARM32 in a handful of places >>>> that needed it. And sometimes we have to be careful and ensure that >>>> ifdef chains check AARCH64 before they check ARM. >>>> >>>> This has all been working quite nicely, as the include guards used, for >>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which are >>>> never >>>> defined at the same time (derived from HOTSPOT_TARGET_CPU_ARCH). >> But >>>> the >>>> current changes remove those unique defines and, before the HEADER_H >>>> forms were introduced, tried to use simple AARCH64 and ARM as include >>>> guards, and that doesn't work as they are not mutually exclusive. >>>> >>>> So what I'm suggesting is just not getting rid of those defines, but >>>> keeping them so they can be used as include guards (or other conditional >>>> code) when needed, and where the macros are not suitable. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> I have no idea what hardware is addressed by your closed ports, >>>>> nor how you merge sources. >>>>> Is there also a port that sets >>>>> -DTARGET_ARCH_arm >>>>> -DARM >>>>> -DARM32 >>>>> ? >>>>> >>>>> To fix this either you define >>>>> #if defined(ARM) && defined(_LP64) >>>>> #define ARM64 >>>>> #endif >>>>> in macros.hpp or you set -DARM64 on the command line. >>>>> Then you replace all >>>>> #ifdef AARCH64 >>>>> by >>>>> #if defined(AARCH64) || defined(ARM64) >>>>> or maybe it suffices altogether f you replace >>>>> #ifdef AARCH64 >>>>> by >>>>> #if defined(AARCH64) || defined(ARM) >>>>> >>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>> that you have a 32-bit port. Therefore we set up these macros >>>>> as on x86, where there is one for the arch (X86) and two for LP64/!LP64 >>>>> (IA32, AMD64). This allowed to separate code for the closed port >>>>> (guarded by PPC32), the open port (PPC64) and shared for both (PPC). >>>>> >>>>> But I don't think it is necessary to do any further changes now, assuming >>>>> my change works for you as I adapted it. So we're all set I guess! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >>>>>>>> workaround is obscure - you have to know that the Open Aarch64 >> port >>>>>>>> defines AARCH64 but not ARM and so that code is for the Open port >>>> use >>>>>>>> only. There's no issue for the OS defines, but I wonder - just >> something >>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>> >>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>> And I'm uneasy that it is no more. How do you handle that? You have >> to >>>>>>> check every AARCH change by RedHat against your closed port? >>>>>> >>>>>> The sources for the two ports are distinct so the only place we have to >>>>>> have a convention is in shared code that has CPU specific stuff and in >>>>>> the build files. >>>>>> >>>>>> The open Aarch64 port sets (among others): >>>>>> -DTARGET_ARCH_aarch64 >>>>>> -DAARCH64 >>>>>> >>>>>> the closed port sets >>>>>> >>>>>> -DTARGET_ARCH_arm >>>>>> -DARM >>>>>> -DAARCH64 >>>>>> >>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >>>> Whenever >>>>>> you saw TARGET_ARCH_arm in open shared code it is/was referring to >>>> our >>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 >> port. >>>>>> >>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>> >>>>>> We need to keep a clear distinction. Using the combination of AARCH64 >>>>>> and ARM is not so clear. >>>>>> >>>>>> You could easily have similar issues with other port groups - eg ppc64 >>>>>> vs ppc32 vs ppcle. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I don't know about the closed stuff, but aarch came up recently, and >>>>>>> before that it sure was equivalent. And it still is the case for openJDK. >>>>>>> >>>>>>> Below output is grepped out of the make//platform_ files >> in >>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined twice. >>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - >>>>>> DAMD64 >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE - >>>> DIA32 >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - >> DZERO - >>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> Thanks Goetz. Will get back to you asap if there are any further >> issues, >>>>>>>> but the incremental changes look okay. >>>>>>>> >>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I added macros for C headers: >>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>> and fixed the other issues mentioned by David and Coleen in this >> new >>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>> newPfmIncl/webrev.03/ >>>>>>>>> >>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>> at the same time. >>>>>>>>> >>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>> >>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind of >>>>>>>> workaround is obscure - you have to know that the Open Aarch64 >> port >>>>>>>> defines AARCH64 but not ARM and so that code is for the Open port >>>> use >>>>>>>> only. There's no issue for the OS defines, but I wonder - just >> something >>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> My incremental changes are in this patch: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be fixed >>>>>>>>>>>> in the closed code. >>>>>>>>>>> >>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>>>>>>>> >>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for the >>>> ifdef >>>>>> is >>>>>>>> not >>>>>>>>>>> going to work for our closed ports, unless I change that value to >>>>>> match >>>>>>>>>>> the open naming scheme. But that in turn will lead to other >>>> problems >>>>>> as >>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>> >>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>> >>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. In >>>> general >>>>>> you >>>>>>>>>> can't just replace: >>>>>>>>>> >>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>> >>>>>>>>>> with >>>>>>>>>> >>>>>>>>>> #ifdef abc >>>>>>>>>> >>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our case >> ARM >>>>>> and >>>>>>>>>> AARCH64 are both defined and are both needed. In contrast >>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to >>>> represent >>>>>> the >>>>>>>>>> architecture in this context. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, >> that >>>>>>>>>> appends.h >>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used >> only >>>>>> once. >>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to get >> is >>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We actually need this as the simple arch names need not >> be >>>>>>>> mutually >>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be >> an >>>> if- >>>>>>>> else >>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>> >>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the closed >>>> part >>>>>> of >>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get >> both >>>>>>>> defined >>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to understand >>>> what >>>>>>>> the >>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, as >> we >>>>>> are >>>>>>>> not >>>>>>>>>>>>> overriding it for our port - which I think is the current problem, >>>> but >>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and >>>> comments >>>>>>>>>> below. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch directory, but >> I >>>>>> don't >>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. (Sorry I >>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs to >> be >>>>>>>> changed >>>>>>>>>> on >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that has >> the >>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 header >>>> files if >>>>>> I >>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches >> internally >>>> for >>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>> But this was rather small. And there anyways was a >> common >>>> file >>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this >> kind >>>> of >>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>>>>>>>>>> Actually I think the implementation should be moved to >>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Not clear why the platform include can simply be elided >>>> here ?? >>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the >>>> umbrella >>>>>>>> header >>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends .hpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, >> that >>>>>>>>>> appends.h >>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used >> only >>>>>> once. >>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to get >> is >>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We actually need this as the simple arch names need not >> be >>>>>>>> mutually >>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to be >> an >>>> if- >>>>>>>> else >>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is that >>>>>> coming >>>>>>>>>> from >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >> WINDOWS >>>> in >>>>>> the >>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is defining - >>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but not >> in >>>> this >>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the unused >>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; >>>> Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's working on >> all >>>> the >>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the macros >> and >>>>>> not >>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>> construction >>>>>> are >>>>>>>> in >>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. But >>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses the >>>> very >>>>>>>> same >>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include >> that >>>> in >>>>>> the >>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine >> with >>>> your >>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that the >>>> linux=1 >>>>>>>> etc >>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should be >>>> upper >>>>>> case? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>> From: Kim Barrett [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>> >>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- >>>> compiler- >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> please take into account that these macros are >> only >>>>>> used >>>>>>>>>> within >>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs to >>>>>>>> understand >>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and >>>> expands to >>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to spend >> days >>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my >> current >>>>>>>> progress >>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is >> adding >>>> the >>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >> proposed >>>> in >>>>>> that >>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email thread for >>>> me; it >>>>>>>> looks >>>>>>>>>>>>> like >>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev but >>>> not >>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this >>>> morning. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've only >>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait >> until >>>> the >>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------- >> --- >>>> ---- >>>>>> --- >>>>>>>> --- >>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing >> #defines >>>>>> that >>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: >> linux=1, >>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the leading >>>>>> underscore >>>>>>>>>> part >>>>>>>>>>>>> of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>> 67 - >>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>> \ >>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets instead >> of >>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are >> defined, >>>> but >>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >> underscore >>>>>>>>>> followed >>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word pattern >>>> for >>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase for >>>> the >>>>>>>> macro >>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------- >> --- >>>> ---- >>>>>> --- >>>>>>>> --- >>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Wed Jul 20 10:32:56 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jul 2016 10:32:56 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <3a73f75307714e1abf34312333be7a33@DEWDFE13DE09.global.corp.sap> <89accd81-8ada-d58a-dec5-ccd555cac6d0@oracle.com> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> Message-ID: <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> Hi New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.04/ It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in CompileJvm.gmk and reverts the change to the aarch define in vmStructs_jvmci.cpp. I documented what I learned about the platform defines in macros.hpp. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 20. Juli 2016 12:05 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > OK, to get this through I will add > > -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > > and revert this one and only place it needs to be used in the > vmStructs_jvmci.cpp. > > Thanks. > > > For the records, openJdk aarch64 has a C1 port. And yes, such cleanups > should > > not be in this change. > > I did not know they had a 64-bit C1 - interesting. > > > > > Thanks for doing the closed changes! > > You're welcome. > > Cheers, > David > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 20. Juli 2016 11:13 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> Hi Goetz, > >> > >> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> that's great what you are saying and just the design I would expect! > >>>> We did not want to have to > >>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so > >>>> we worked with the Open port to ensure that shared code guarded by > >>>> AARCH64 is suitable for both. We also ensured ARM was used to > identify > >>>> word-size agnostic code and we introduced ARM32 in a handful of > places > >>>> that needed it. And sometimes we have to be careful and ensure that > >>>> ifdef chains check AARCH64 before they check ARM. > >>> > >>> I think as a consequence the open AARCH port should define ARM, too. > >> > >> I would not want to do this and certainly not as part of this change. > >> If/when the Aarch32 port arrives we may have to revisit this, but not > >> right now, please. > >> > >>> I checked the occurrences and only see three places where this would > have > >>> an effect and would have to be fixed somehow: > >>> > >>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>> [610] #if defined(AARCH64) && !defined(ARM) > >>> ==> Would this break the closed port if defined? > >> > >> Yes - it refers to specific piece of code in the open aarch64 sources. > >> > >>> (This is the only place where TARGET_ARCH_aarch64 was used) > >>> > >>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) > >>> ==> Would this break the open port if defined? > >>> > >>> *** share/vm/c1/c1_Runtime1.cpp: > >>> [1154] #ifdef ARM > >>> ==> Would this break the open port if defined? > >> > >> I don't think the open port has C1 so it would ignore the above files > >> anyway. > >> > >>> All the cases below are pointless. > >>> > >>>> So what I'm suggesting is just not getting rid of those defines, but > >>>> keeping them so they can be used as include guards (or other > conditional > >>>> code) when needed, and where the macros are not suitable. > >>> I think it's quite misleading to have two defines that are 99% equivalent. > >>> If we really need a special case here, you should define -DARM_CLOSED > >>> or the like in your closed port. Such a name would make clear what's the > >>> issue. At least, only your closed port has this problem. > >> > >> I really do not want to make any changes to this - ignoring the include > >> macro changes everything we have is working perfectly fine just the way > >> the defines are. So I don't want to see this change potentially break > >> that through incidental changes. > >> > >> I do not see having the following is a big issue: > >> > >> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >> > >> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and > >> TARGET_ARCH_arm to mean whatever the owners of that define intend > it to > >> mean. It certainly is a lot better than interpreting what the > >> combinations of AARCH64 and ARM mean. Keeping this removes the > need to > >> perform some of the changes as noted above. > >> > >> I'm preparing the review of the internal changes we need to accompany > this. > >> > >> Thanks, > >> David > >> ----- > >> > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>> These should not break the open port if ARM gets defined, or can be > fixed > >> easily. > >>> --------------------------------------------------------- > >>> > >>> *** share/vm/c1/c1_LIR.cpp: > >>> print[1519] #elif defined(ARM) > >>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>> > >>> *** os/linux/vm/os_linux.cpp: > >>> dll_load[1796] #elif (defined ARM) > >>> get_summary_cpu_info[2273] #elif defined(ARM) > >>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>> > >>> *** share/vm/opto/matcher.cpp: > >>> init_first_stack_mask[558] #ifdef ARM > >>> ==> Should be ARM32 (Is under !LP64). > >>> > >>> *** share/vm/c1/c1_LIR.cpp: > >>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > >>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > >>> ==> Just an assertion. Will just relax the check if defined in open > AARCH64. > >>> But maybe should be guarded by __SOFTFP__. > >>> [70] #if defined(ARM) || defined(AARCH64) || > >> defined(PPC64) > >>> ==> Fine: || > >>> > >>> *** share/vm/c1/c1_LIR.hpp: > >>> [447] #if defined(SPARC) || defined(ARM) || > >> defined(PPC) || defined(AARCH64) > >>> [537] #if defined(X86) || defined(ARM) || > >> defined(AARCH64) > >>> ==> Fine: || > >>> > >>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>> defined[162] #if defined(IA32) || defined(AMD64) || > >> defined(ARM) > >>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>> [1358] #if defined(IA32) || defined(AMD64) || > >> defined(ARM) > >>> ==> Just defines a method which would be unused, should be fine. > >>> > >>> > >>> These are in code not used in the open AARCH64 port: > >>> -------------------------------------------------- > >>> > >>> *** os/bsd/vm/os_bsd.cpp: > >>> [215] #elif defined(ARM) > >>> > >>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>> [102] #ifdef ARM > >>> > >>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>> [31] #ifdef ARM > >>> > >>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>> [102] #ifdef ARM > >>> > >>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>> [31] #ifdef ARM > >>> > >>> *** share/vm/utilities/macros.hpp: > >>> [434] #ifdef ARM > >>> > >>> *** os/bsd/vm/os_bsd.cpp: > >>> dll_load[1508] #elif (defined ARM) > >>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, > >> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>> > >>> *** os/solaris/vm/os_solaris.cpp: > >>> dll_load[1725] #elif (defined ARM) > >>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, > >> ARM > >>> > >>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>> store[164] #if !defined(ARM) && !defined(M68K) > >>> store_ptr[171] #if !defined(ARM) && !defined(M68K) > >>> add[178] #ifdef ARM > >>> add_ptr[190] #ifdef ARM > >>> xchg[230] #ifdef ARM > >>> xchg_ptr[253] #ifdef ARM > >>> cmpxchg[275] #ifdef ARM > >>> cmpxchg_ptr[298] #ifdef ARM > >>> > >>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>> add[172] #ifdef ARM > >>> add_ptr[184] #ifdef ARM > >>> xchg[224] #ifdef ARM > >>> xchg_ptr[247] #ifdef ARM > >>> cmpxchg[269] #ifdef ARM > >>> cmpxchg_ptr[292] #ifdef ARM > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> we also have "closed ports", currently HPUX, ia64 and s390. > >>>>> (Parisc is gone, puh!). > >>>>> We basically patch all the shared changes onto the sources after > >>>>> getting them via our licensee channel. > >>>>> I think you should fix your closed port not to re-use the names of the > >>>>> main openJdk platforms! > >>>> > >>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to have > to > >>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so > >>>> we worked with the Open port to ensure that shared code guarded by > >>>> AARCH64 is suitable for both. We also ensured ARM was used to > identify > >>>> word-size agnostic code and we introduced ARM32 in a handful of > places > >>>> that needed it. And sometimes we have to be careful and ensure that > >>>> ifdef chains check AARCH64 before they check ARM. > >>>> > >>>> This has all been working quite nicely, as the include guards used, for > >>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which > are > >>>> never > >>>> defined at the same time (derived from > HOTSPOT_TARGET_CPU_ARCH). > >> But > >>>> the > >>>> current changes remove those unique defines and, before the > HEADER_H > >>>> forms were introduced, tried to use simple AARCH64 and ARM as > include > >>>> guards, and that doesn't work as they are not mutually exclusive. > >>>> > >>>> So what I'm suggesting is just not getting rid of those defines, but > >>>> keeping them so they can be used as include guards (or other > conditional > >>>> code) when needed, and where the macros are not suitable. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> I have no idea what hardware is addressed by your closed ports, > >>>>> nor how you merge sources. > >>>>> Is there also a port that sets > >>>>> -DTARGET_ARCH_arm > >>>>> -DARM > >>>>> -DARM32 > >>>>> ? > >>>>> > >>>>> To fix this either you define > >>>>> #if defined(ARM) && defined(_LP64) > >>>>> #define ARM64 > >>>>> #endif > >>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>> Then you replace all > >>>>> #ifdef AARCH64 > >>>>> by > >>>>> #if defined(AARCH64) || defined(ARM64) > >>>>> or maybe it suffices altogether f you replace > >>>>> #ifdef AARCH64 > >>>>> by > >>>>> #if defined(AARCH64) || defined(ARM) > >>>>> > >>>>> For ppc, when we did the port we knew (and that's all we knew) > >>>>> that you have a 32-bit port. Therefore we set up these macros > >>>>> as on x86, where there is one for the arch (X86) and two for > LP64/!LP64 > >>>>> (IA32, AMD64). This allowed to separate code for the closed port > >>>>> (guarded by PPC32), the open port (PPC64) and shared for both > (PPC). > >>>>> > >>>>> But I don't think it is necessary to do any further changes now, > assuming > >>>>> my change works for you as I adapted it. So we're all set I guess! > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind > of > >>>>>>>> workaround is obscure - you have to know that the Open Aarch64 > >> port > >>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > port > >>>> use > >>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >> something > >>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>> > >>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>> And I'm uneasy that it is no more. How do you handle that? You > have > >> to > >>>>>>> check every AARCH change by RedHat against your closed port? > >>>>>> > >>>>>> The sources for the two ports are distinct so the only place we have > to > >>>>>> have a convention is in shared code that has CPU specific stuff and in > >>>>>> the build files. > >>>>>> > >>>>>> The open Aarch64 port sets (among others): > >>>>>> -DTARGET_ARCH_aarch64 > >>>>>> -DAARCH64 > >>>>>> > >>>>>> the closed port sets > >>>>>> > >>>>>> -DTARGET_ARCH_arm > >>>>>> -DARM > >>>>>> -DAARCH64 > >>>>>> > >>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. > >>>> Whenever > >>>>>> you saw TARGET_ARCH_arm in open shared code it is/was referring > to > >>>> our > >>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 > >> port. > >>>>>> > >>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >>>>>> > >>>>>> We need to keep a clear distinction. Using the combination of > AARCH64 > >>>>>> and ARM is not so clear. > >>>>>> > >>>>>> You could easily have similar issues with other port groups - eg ppc64 > >>>>>> vs ppc32 vs ppcle. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> I don't know about the closed stuff, but aarch came up recently, > and > >>>>>>> before that it sure was equivalent. And it still is the case for > openJDK. > >>>>>>> > >>>>>>> Below output is grepped out of the make//platform_ > files > >> in > >>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined twice. > >>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE > - > >>>>>> DAMD64 > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE > - > >>>> DIA32 > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - > DCC_INTERP > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - > >> DZERO - > >>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> Thanks Goetz. Will get back to you asap if there are any further > >> issues, > >>>>>>>> but the incremental changes look okay. > >>>>>>>> > >>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I added macros for C headers: > >>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>> and fixed the other issues mentioned by David and Coleen in this > >> new > >>>>>>>> webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>> newPfmIncl/webrev.03/ > >>>>>>>>> > >>>>>>>>> I also added comments that AARCH64 and ARM are defined > >>>>>>>>> at the same time. > >>>>>>>>> > >>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>> > >>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind > of > >>>>>>>> workaround is obscure - you have to know that the Open Aarch64 > >> port > >>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > port > >>>> use > >>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >> something > >>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> My incremental changes are in this patch: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> Hi Goetz, > >>>>>>>>>> > >>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>> Hi David, > >>>>>>>>>>>> > >>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be > fixed > >>>>>>>>>>>> in the closed code. > >>>>>>>>>>> > >>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>>>>>>>> > >>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for > the > >>>> ifdef > >>>>>> is > >>>>>>>> not > >>>>>>>>>>> going to work for our closed ports, unless I change that value > to > >>>>>> match > >>>>>>>>>>> the open naming scheme. But that in turn will lead to other > >>>> problems > >>>>>> as > >>>>>>>>>>> we also need that value the way it is currently defined. > >>>>>>>>>>> > >>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>>>> > >>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. In > >>>> general > >>>>>> you > >>>>>>>>>> can't just replace: > >>>>>>>>>> > >>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>> > >>>>>>>>>> with > >>>>>>>>>> > >>>>>>>>>> #ifdef abc > >>>>>>>>>> > >>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our case > >> ARM > >>>>>> and > >>>>>>>>>> AARCH64 are both defined and are both needed. In contrast > >>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to > >>>> represent > >>>>>> the > >>>>>>>>>> architecture in this context. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> David > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Goetz. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>> Barrett > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > .hpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, > >> that > >>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used > >> only > >>>>>> once. > >>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to > get > >> is > >>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We actually need this as the simple arch names need not > >> be > >>>>>>>> mutually > >>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to > be > >> an > >>>> if- > >>>>>>>> else > >>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>> They should be mutually exclusive, as they are set in > >>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the > closed > >>>> part > >>>>>> of > >>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get > >> both > >>>>>>>> defined > >>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to > understand > >>>> what > >>>>>>>> the > >>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, > as > >> we > >>>>>> are > >>>>>>>> not > >>>>>>>>>>>>> overriding it for our port - which I think is the current > problem, > >>>> but > >>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > >> Kim > >>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >>>> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>>> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and > >>>> comments > >>>>>>>>>> below. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch directory, > but > >> I > >>>>>> don't > >>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. > (Sorry I > >>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs to > >> be > >>>>>>>> changed > >>>>>>>>>> on > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that has > >> the > >>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 > header > >>>> files if > >>>>>> I > >>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches > >> internally > >>>> for > >>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: > >>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>> But this was rather small. And there anyways was a > >> common > >>>> file > >>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this > >> kind > >>>> of > >>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... > >>>>>>>>>>>>>>>> Actually I think the implementation should be moved to > >>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Not clear why the platform include can simply be > elided > >>>> here ?? > >>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the > >>>> umbrella > >>>>>>>> header > >>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > .hpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, > >> that > >>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used > >> only > >>>>>> once. > >>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to > get > >> is > >>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We actually need this as the simple arch names need not > >> be > >>>>>>>> mutually > >>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to > be > >> an > >>>> if- > >>>>>>>> else > >>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is > that > >>>>>> coming > >>>>>>>>>> from > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined > >> WINDOWS > >>>> in > >>>>>> the > >>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is defining > - > >>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but > not > >> in > >>>> this > >>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the > unused > >>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; > >>>> Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's working > on > >> all > >>>> the > >>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the > macros > >> and > >>>>>> not > >>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name > >>>> construction > >>>>>> are > >>>>>>>> in > >>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. > But > >>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses > the > >>>> very > >>>>>>>> same > >>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include > >> that > >>>> in > >>>>>> the > >>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine > >> with > >>>> your > >>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that > the > >>>> linux=1 > >>>>>>>> etc > >>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should be > >>>> upper > >>>>>> case? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>> > >>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- > >>>> compiler- > >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>> platform > >>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz > >>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> please take into account that these macros are > >> only > >>>>>> used > >>>>>>>>>> within > >>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs > to > >>>>>>>> understand > >>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and > >>>> expands to > >>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to > spend > >> days > >>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my > >> current > >>>>>>>> progress > >>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is > >> adding > >>>> the > >>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>> > http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker > >> proposed > >>>> in > >>>>>> that > >>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>> > http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email thread > for > >>>> me; it > >>>>>>>> looks > >>>>>>>>>>>>> like > >>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev > but > >>>> not > >>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this > >>>> morning. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've > only > >>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait > >> until > >>>> the > >>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------- > ---- > >> --- > >>>> ---- > >>>>>> --- > >>>>>>>> --- > >>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing > >> #defines > >>>>>> that > >>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: > >> linux=1, > >>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the leading > >>>>>> underscore > >>>>>>>>>> part > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>> 67 - > >>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>> \ > >>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>> > DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>> > XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets > instead > >> of > >>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are > >> defined, > >>>> but > >>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that > >> underscore > >>>>>>>>>> followed > >>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word > pattern > >>>> for > >>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase > for > >>>> the > >>>>>>>> macro > >>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------- > ---- > >> --- > >>>> ---- > >>>>>> --- > >>>>>>>> --- > >>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> From marcus.larsson at oracle.com Wed Jul 20 10:55:05 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 20 Jul 2016 12:55:05 +0200 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: <31036a63-bb39-6cf7-427d-00a42b3f1ab4@oracle.com> References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> <31036a63-bb39-6cf7-427d-00a42b3f1ab4@oracle.com> Message-ID: Hi again, Updated the patch with additional comments. Also fixed the copyright header. New webrev: http://cr.openjdk.java.net/~mlarsson/8061219/webrev.01/ Incremental: http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00-01/ Thanks, Marcus On 2016-07-19 10:25, Marcus Larsson wrote: > Still looking for a *R*eviewer for this. > > Thanks, > Marcus > > > On 07/18/2016 10:49 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add unit tests for the unified >> logging framework. Tests are written for the new gtest unit test >> framework. Most of the public functions for UL should be covered, but >> later additions have internal vm tests (in log.cpp) that will be >> ported separately. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8061219 >> >> Testing: >> New tests through JPRT >> >> Thanks, >> Marcus > From daniel.daugherty at oracle.com Wed Jul 20 17:46:05 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 11:46:05 -0600 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev Message-ID: Greetings, The July CPU changes landed in JDK9-dev last night and we're working through the ripples... We need to quarantine a test so that JDK9-dev can be merged with JDK9-hs: $ hg -R hotspot diff diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 2016 -0400 +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 2016 -0700 @@ -26,6 +26,7 @@ * @summary Verifies that getUnsafe() actually throws SecurityException when unsafeAccess is prohibited. * @library /testlibrary * @modules java.base/jdk.internal.misc + * @ignore 8161947 * @run main GetUnsafe */ I'm invoking the HotSpot Trivial Change rule so I only need one (R)eviewer and I'll be pushing this changeset to JDK9-dev. Thanks, in advance, for any comments, questions or suggestions. Dan From jiangli.zhou at oracle.com Wed Jul 20 17:45:47 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 20 Jul 2016 10:45:47 -0700 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev In-Reply-To: References: Message-ID: <5AD71D30-3BF2-46E7-926B-7DCD53CC26C4@oracle.com> Hi Dan, This looks good. Thanks, Jiangli > On Jul 20, 2016, at 10:46 AM, Daniel D. Daugherty wrote: > > Greetings, > > The July CPU changes landed in JDK9-dev last night and we're working through > the ripples... We need to quarantine a test so that JDK9-dev can be merged > with JDK9-hs: > > $ hg -R hotspot diff > diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java > --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 2016 -0400 > +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 2016 -0700 > @@ -26,6 +26,7 @@ > * @summary Verifies that getUnsafe() actually throws SecurityException when unsafeAccess is prohibited. > * @library /testlibrary > * @modules java.base/jdk.internal.misc > + * @ignore 8161947 > * @run main GetUnsafe > */ > > > I'm invoking the HotSpot Trivial Change rule so I only need one > (R)eviewer and I'll be pushing this changeset to JDK9-dev. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From george.triantafillou at oracle.com Wed Jul 20 17:48:40 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 20 Jul 2016 13:48:40 -0400 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev In-Reply-To: <5AD71D30-3BF2-46E7-926B-7DCD53CC26C4@oracle.com> References: <5AD71D30-3BF2-46E7-926B-7DCD53CC26C4@oracle.com> Message-ID: <3796cc4e-8f10-f5d8-0dcb-905185306859@oracle.com> +1 -George On 7/20/2016 1:45 PM, Jiangli Zhou wrote: > Hi Dan, > > This looks good. > > Thanks, > Jiangli > >> On Jul 20, 2016, at 10:46 AM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> The July CPU changes landed in JDK9-dev last night and we're working through >> the ripples... We need to quarantine a test so that JDK9-dev can be merged >> with JDK9-hs: >> >> $ hg -R hotspot diff >> diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java >> --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 2016 -0400 >> +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 2016 -0700 >> @@ -26,6 +26,7 @@ >> * @summary Verifies that getUnsafe() actually throws SecurityException when unsafeAccess is prohibited. >> * @library /testlibrary >> * @modules java.base/jdk.internal.misc >> + * @ignore 8161947 >> * @run main GetUnsafe >> */ >> >> >> I'm invoking the HotSpot Trivial Change rule so I only need one >> (R)eviewer and I'll be pushing this changeset to JDK9-dev. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From daniel.daugherty at oracle.com Wed Jul 20 17:55:42 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 11:55:42 -0600 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev In-Reply-To: <5AD71D30-3BF2-46E7-926B-7DCD53CC26C4@oracle.com> References: <5AD71D30-3BF2-46E7-926B-7DCD53CC26C4@oracle.com> Message-ID: <0fdb0888-5ad3-eb43-9493-23380f911518@oracle.com> Thanks Jiangli! Dan On 7/20/16 11:45 AM, Jiangli Zhou wrote: > Hi Dan, > > This looks good. > > Thanks, > Jiangli > >> On Jul 20, 2016, at 10:46 AM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> The July CPU changes landed in JDK9-dev last night and we're working through >> the ripples... We need to quarantine a test so that JDK9-dev can be merged >> with JDK9-hs: >> >> $ hg -R hotspot diff >> diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java >> --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 2016 -0400 >> +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 2016 -0700 >> @@ -26,6 +26,7 @@ >> * @summary Verifies that getUnsafe() actually throws SecurityException when unsafeAccess is prohibited. >> * @library /testlibrary >> * @modules java.base/jdk.internal.misc >> + * @ignore 8161947 >> * @run main GetUnsafe >> */ >> >> >> I'm invoking the HotSpot Trivial Change rule so I only need one >> (R)eviewer and I'll be pushing this changeset to JDK9-dev. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From daniel.daugherty at oracle.com Wed Jul 20 17:57:42 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 11:57:42 -0600 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev In-Reply-To: <3796cc4e-8f10-f5d8-0dcb-905185306859@oracle.com> References: <5AD71D30-3BF2-46E7-926B-7DCD53CC26C4@oracle.com> <3796cc4e-8f10-f5d8-0dcb-905185306859@oracle.com> Message-ID: Thanks George! Dan On 7/20/16 11:48 AM, George Triantafillou wrote: > +1 > > -George > > On 7/20/2016 1:45 PM, Jiangli Zhou wrote: >> Hi Dan, >> >> This looks good. >> >> Thanks, >> Jiangli >> >>> On Jul 20, 2016, at 10:46 AM, Daniel D. Daugherty >>> wrote: >>> >>> Greetings, >>> >>> The July CPU changes landed in JDK9-dev last night and we're working >>> through >>> the ripples... We need to quarantine a test so that JDK9-dev can be >>> merged >>> with JDK9-hs: >>> >>> $ hg -R hotspot diff >>> diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java >>> --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 >>> 2016 -0400 >>> +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 >>> 2016 -0700 >>> @@ -26,6 +26,7 @@ >>> * @summary Verifies that getUnsafe() actually throws >>> SecurityException when unsafeAccess is prohibited. >>> * @library /testlibrary >>> * @modules java.base/jdk.internal.misc >>> + * @ignore 8161947 >>> * @run main GetUnsafe >>> */ >>> >>> >>> I'm invoking the HotSpot Trivial Change rule so I only need one >>> (R)eviewer and I'll be pushing this changeset to JDK9-dev. >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan > From Alan.Bateman at oracle.com Wed Jul 20 17:57:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Jul 2016 18:57:17 +0100 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev In-Reply-To: References: Message-ID: <8520a812-4dac-e7d7-06b2-b348317e268b@oracle.com> On 20/07/2016 18:46, Daniel D. Daugherty wrote: > Greetings, > > The July CPU changes landed in JDK9-dev last night and we're working > through > the ripples... We need to quarantine a test so that JDK9-dev can be > merged > with JDK9-hs: > > $ hg -R hotspot diff > diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java > --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 > 2016 -0400 > +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 > 2016 -0700 > @@ -26,6 +26,7 @@ > * @summary Verifies that getUnsafe() actually throws > SecurityException when unsafeAccess is prohibited. > * @library /testlibrary > * @modules java.base/jdk.internal.misc > + * @ignore 8161947 > * @run main GetUnsafe > */ > Alternatively remove the test as it doesn't make sense for jdk.internal.misc.Unsafe or change it to use sun.misc.Unsafe so that it tests what it was originally meant to test. -Alan From daniel.daugherty at oracle.com Wed Jul 20 18:04:37 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 12:04:37 -0600 Subject: URGENT RFR(XXXS): 8161949 quarantine runtime/Unsafe/GetUnsafe.java to allow sync with JDK9-dev In-Reply-To: <8520a812-4dac-e7d7-06b2-b348317e268b@oracle.com> References: <8520a812-4dac-e7d7-06b2-b348317e268b@oracle.com> Message-ID: On 7/20/16 11:57 AM, Alan Bateman wrote: > > > On 20/07/2016 18:46, Daniel D. Daugherty wrote: >> Greetings, >> >> The July CPU changes landed in JDK9-dev last night and we're working >> through >> the ripples... We need to quarantine a test so that JDK9-dev can be >> merged >> with JDK9-hs: >> >> $ hg -R hotspot diff >> diff -r 9b01ac7cc018 test/runtime/Unsafe/GetUnsafe.java >> --- a/test/runtime/Unsafe/GetUnsafe.java Wed May 11 12:03:46 >> 2016 -0400 >> +++ b/test/runtime/Unsafe/GetUnsafe.java Wed Jul 20 10:37:35 >> 2016 -0700 >> @@ -26,6 +26,7 @@ >> * @summary Verifies that getUnsafe() actually throws >> SecurityException when unsafeAccess is prohibited. >> * @library /testlibrary >> * @modules java.base/jdk.internal.misc >> + * @ignore 8161947 >> * @run main GetUnsafe >> */ >> > Alternatively remove the test as it doesn't make sense for > jdk.internal.misc.Unsafe or change it to use sun.misc.Unsafe so that > it tests what it was originally meant to test. I think removing/revising the test in light of recent Unsafe changes is happening via a different bug ID... For today's fire drill, I'm just trying to make the merge possible for Alejandro... Dan > > -Alan From daniel.daugherty at oracle.com Wed Jul 20 19:42:45 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 13:42:45 -0600 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: <2d52bf8e-c201-3bc9-8522-fc1986405fba@oracle.com> On 7/17/16 5:05 PM, harold seigel wrote: > Hi, > > Please review these Hotspot VM only changes to process the seven > module-specific options that have been renamed to have gnu-like > names. JDK changes for this bug will be reviewed separately. > > Descriptions of these options are here > . For these six options, > --module-path, --upgrade-module-path, --add-modules, --limit-modules, > --add-reads, and --add-exports, the JVM just sets a system property. > For the --patch-module option, the JVM sets a system property and then > processes the option in the same way as when it was named -Xpatch. > > Additionally, the JVM now checks properties specified on the command > line. If a property matches one of the properties used by one of the > above options then the JVM ignores the property. This forces users to > use the explicit option when wanting to do things like add a module or > a package export. Based on conversations with Harold, the JVM will _silently_ ignore the specific properties if they are specified on the command line. Silently ignoring the properties will likely lead to bugs being filed even if we put a line or two in a man page somewhere. It seems useful for us to issue a warning or an error if the user tries to specify properties on the command line that we don't want to be specified. I poked around the bugs and I don't see a rationale for the silently ignore behavior. Can someone please explain? Dan > > The RFR contains two new tests. Also, many existing tests were > changed to use the new option names. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ > > The changes were tested with the JCK lang and VM tests, the JTreg > hotspot tests, and the RBT hotspot nightlies. > > Thanks, Harold From harold.seigel at oracle.com Wed Jul 20 19:48:48 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 20 Jul 2016 15:48:48 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <2d52bf8e-c201-3bc9-8522-fc1986405fba@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <2d52bf8e-c201-3bc9-8522-fc1986405fba@oracle.com> Message-ID: Hi Dan, This was discussed today and it was decided the the JVM will issue warnings if these specific properties are specified on the command line, provided that option PrintWarnings is TRUE. This will probably be done as a separate bug. Thanks, Harold On 7/20/2016 3:42 PM, Daniel D. Daugherty wrote: > On 7/17/16 5:05 PM, harold seigel wrote: >> Hi, >> >> Please review these Hotspot VM only changes to process the seven >> module-specific options that have been renamed to have gnu-like >> names. JDK changes for this bug will be reviewed separately. >> >> Descriptions of these options are here >> . For these six options, >> --module-path, --upgrade-module-path, --add-modules, --limit-modules, >> --add-reads, and --add-exports, the JVM just sets a system property. >> For the --patch-module option, the JVM sets a system property and >> then processes the option in the same way as when it was named -Xpatch. >> >> Additionally, the JVM now checks properties specified on the command >> line. If a property matches one of the properties used by one of the >> above options then the JVM ignores the property. This forces users to >> use the explicit option when wanting to do things like add a module >> or a package export. > > Based on conversations with Harold, the JVM will _silently_ ignore the > specific properties if they are specified on the command line. Silently > ignoring the properties will likely lead to bugs being filed even if we > put a line or two in a man page somewhere. It seems useful for us to > issue a warning or an error if the user tries to specify properties on > the command line that we don't want to be specified. > > I poked around the bugs and I don't see a rationale for the silently > ignore behavior. Can someone please explain? > > Dan > > >> >> The RFR contains two new tests. Also, many existing tests were >> changed to use the new option names. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >> >> The changes were tested with the JCK lang and VM tests, the JTreg >> hotspot tests, and the RBT hotspot nightlies. >> >> Thanks, Harold > From daniel.daugherty at oracle.com Wed Jul 20 19:52:18 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 13:52:18 -0600 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <2d52bf8e-c201-3bc9-8522-fc1986405fba@oracle.com> Message-ID: Sounds good to me. Thanks! Dan On 7/20/16 1:48 PM, harold seigel wrote: > Hi Dan, > > This was discussed today and it was decided the the JVM will issue > warnings if these specific properties are specified on the command > line, provided that option PrintWarnings is TRUE. This will probably > be done as a separate bug. > > Thanks, Harold > > > On 7/20/2016 3:42 PM, Daniel D. Daugherty wrote: >> On 7/17/16 5:05 PM, harold seigel wrote: >>> Hi, >>> >>> Please review these Hotspot VM only changes to process the seven >>> module-specific options that have been renamed to have gnu-like >>> names. JDK changes for this bug will be reviewed separately. >>> >>> Descriptions of these options are here >>> . For these six options, >>> --module-path, --upgrade-module-path, --add-modules, >>> --limit-modules, --add-reads, and --add-exports, the JVM just sets a >>> system property. For the --patch-module option, the JVM sets a >>> system property and then processes the option in the same way as >>> when it was named -Xpatch. >>> >>> Additionally, the JVM now checks properties specified on the command >>> line. If a property matches one of the properties used by one of >>> the above options then the JVM ignores the property. This forces >>> users to use the explicit option when wanting to do things like add >>> a module or a package export. >> >> Based on conversations with Harold, the JVM will _silently_ ignore the >> specific properties if they are specified on the command line. Silently >> ignoring the properties will likely lead to bugs being filed even if we >> put a line or two in a man page somewhere. It seems useful for us to >> issue a warning or an error if the user tries to specify properties on >> the command line that we don't want to be specified. >> >> I poked around the bugs and I don't see a rationale for the silently >> ignore behavior. Can someone please explain? >> >> Dan >> >> >>> >>> The RFR contains two new tests. Also, many existing tests were >>> changed to use the new option names. >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >>> >>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >>> >>> The changes were tested with the JCK lang and VM tests, the JTreg >>> hotspot tests, and the RBT hotspot nightlies. >>> >>> Thanks, Harold >> > From coleen.phillimore at oracle.com Wed Jul 20 21:47:15 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Jul 2016 17:47:15 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/src/share/vm/runtime/arguments.cpp.udiff.html To check if is_internal_module_property, the numbered ones go to is_matching_numbered_property, but do you also want to disallow: jdk.module.addreads.foo or jdk.module.addreads (with no number?) Why aren't addmods and limitmods allowed be specified more than once on the command line and handled like the other ones? + // options. For example: use "--add-modules java.sql", not "-Djdk.module.addmods=java.sql" Does this comment need an equal sign? http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/test/compiler/unsafe/UnsafeGetConstantField.java.udiff.html Can you fix the indentation? We should add an option -XX:+UseUnsafe to be a shortcut for this: --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED The rest looks good. This implementation looks very clean. Thanks, Coleen On 7/17/16 7:05 PM, harold seigel wrote: > Hi, > > Please review these Hotspot VM only changes to process the seven > module-specific options that have been renamed to have gnu-like > names. JDK changes for this bug will be reviewed separately. > > Descriptions of these options are here > . For these six options, > --module-path, --upgrade-module-path, --add-modules, --limit-modules, > --add-reads, and --add-exports, the JVM just sets a system property. > For the --patch-module option, the JVM sets a system property and then > processes the option in the same way as when it was named -Xpatch. > > Additionally, the JVM now checks properties specified on the command > line. If a property matches one of the properties used by one of the > above options then the JVM ignores the property. This forces users to > use the explicit option when wanting to do things like add a module or > a package export. > > The RFR contains two new tests. Also, many existing tests were > changed to use the new option names. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ > > The changes were tested with the JCK lang and VM tests, the JTreg > hotspot tests, and the RBT hotspot nightlies. > > Thanks, Harold From coleen.phillimore at oracle.com Thu Jul 21 02:30:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Jul 2016 22:30:32 -0400 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> Message-ID: <57f6eeeb-e107-574a-f36f-551cb5f16fd9@oracle.com> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.04/src/cpu/aarch64/vm/vm_version_aarch64.cpp.udiff.html This has a typo +#include OS_HEADER_INLCUDE(os) If everything compiled, then do you really need this? http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.04/src/share/vm/asm/macroAssembler.inline.hpp.udiff.html Strange that Zero included assembler_zero.hpp and the rest included macroAssembler_.hpp You said that Zero builds after this change? http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.04/src/cpu/x86/vm/stubRoutines_x86.hpp.udiff.html #endif // CPU_X86_VM_STUBROUTINES_X86_32_HPP Can you fix this to match (ie remove _32)? Everything else looks great. Thank you! Coleen On 7/20/16 6:32 AM, Lindenmaier, Goetz wrote: > Hi > > New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.04/ > > It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in CompileJvm.gmk > and reverts the change to the aarch define in vmStructs_jvmci.cpp. I documented > what I learned about the platform defines in macros.hpp. > > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. Juli 2016 12:05 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> OK, to get this through I will add >>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>> and revert this one and only place it needs to be used in the >> vmStructs_jvmci.cpp. >> >> Thanks. >> >>> For the records, openJdk aarch64 has a C1 port. And yes, such cleanups >> should >>> not be in this change. >> I did not know they had a 64-bit C1 - interesting. >> >>> Thanks for doing the closed changes! >> You're welcome. >> >> Cheers, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> Hi Goetz, >>>> >>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> that's great what you are saying and just the design I would expect! >>>>>> We did not want to have to >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >>>>>> we worked with the Open port to ensure that shared code guarded by >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >> identify >>>>>> word-size agnostic code and we introduced ARM32 in a handful of >> places >>>>>> that needed it. And sometimes we have to be careful and ensure that >>>>>> ifdef chains check AARCH64 before they check ARM. >>>>> I think as a consequence the open AARCH port should define ARM, too. >>>> I would not want to do this and certainly not as part of this change. >>>> If/when the Aarch32 port arrives we may have to revisit this, but not >>>> right now, please. >>>> >>>>> I checked the occurrences and only see three places where this would >> have >>>>> an effect and would have to be fixed somehow: >>>>> >>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>> [610] #if defined(AARCH64) && !defined(ARM) >>>>> ==> Would this break the closed port if defined? >>>> Yes - it refers to specific piece of code in the open aarch64 sources. >>>> >>>>> (This is the only place where TARGET_ARCH_aarch64 was used) >>>>> >>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) >>>>> ==> Would this break the open port if defined? >>>>> >>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>> [1154] #ifdef ARM >>>>> ==> Would this break the open port if defined? >>>> I don't think the open port has C1 so it would ignore the above files >>>> anyway. >>>> >>>>> All the cases below are pointless. >>>>> >>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>> keeping them so they can be used as include guards (or other >> conditional >>>>>> code) when needed, and where the macros are not suitable. >>>>> I think it's quite misleading to have two defines that are 99% equivalent. >>>>> If we really need a special case here, you should define -DARM_CLOSED >>>>> or the like in your closed port. Such a name would make clear what's the >>>>> issue. At least, only your closed port has this problem. >>>> I really do not want to make any changes to this - ignoring the include >>>> macro changes everything we have is working perfectly fine just the way >>>> the defines are. So I don't want to see this change potentially break >>>> that through incidental changes. >>>> >>>> I do not see having the following is a big issue: >>>> >>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>> >>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>> TARGET_ARCH_arm to mean whatever the owners of that define intend >> it to >>>> mean. It certainly is a lot better than interpreting what the >>>> combinations of AARCH64 and ARM mean. Keeping this removes the >> need to >>>> perform some of the changes as noted above. >>>> >>>> I'm preparing the review of the internal changes we need to accompany >> this. >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> These should not break the open port if ARM gets defined, or can be >> fixed >>>> easily. >>>>> --------------------------------------------------------- >>>>> >>>>> *** share/vm/c1/c1_LIR.cpp: >>>>> print[1519] #elif defined(ARM) >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>> >>>>> *** os/linux/vm/os_linux.cpp: >>>>> dll_load[1796] #elif (defined ARM) >>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>> >>>>> *** share/vm/opto/matcher.cpp: >>>>> init_first_stack_mask[558] #ifdef ARM >>>>> ==> Should be ARM32 (Is under !LP64). >>>>> >>>>> *** share/vm/c1/c1_LIR.cpp: >>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) >>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) >>>>> ==> Just an assertion. Will just relax the check if defined in open >> AARCH64. >>>>> But maybe should be guarded by __SOFTFP__. >>>>> [70] #if defined(ARM) || defined(AARCH64) || >>>> defined(PPC64) >>>>> ==> Fine: || >>>>> >>>>> *** share/vm/c1/c1_LIR.hpp: >>>>> [447] #if defined(SPARC) || defined(ARM) || >>>> defined(PPC) || defined(AARCH64) >>>>> [537] #if defined(X86) || defined(ARM) || >>>> defined(AARCH64) >>>>> ==> Fine: || >>>>> >>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>> defined[162] #if defined(IA32) || defined(AMD64) || >>>> defined(ARM) >>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>> [1358] #if defined(IA32) || defined(AMD64) || >>>> defined(ARM) >>>>> ==> Just defines a method which would be unused, should be fine. >>>>> >>>>> >>>>> These are in code not used in the open AARCH64 port: >>>>> -------------------------------------------------- >>>>> >>>>> *** os/bsd/vm/os_bsd.cpp: >>>>> [215] #elif defined(ARM) >>>>> >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>> [102] #ifdef ARM >>>>> >>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>> [31] #ifdef ARM >>>>> >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>> [102] #ifdef ARM >>>>> >>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>> [31] #ifdef ARM >>>>> >>>>> *** share/vm/utilities/macros.hpp: >>>>> [434] #ifdef ARM >>>>> >>>>> *** os/bsd/vm/os_bsd.cpp: >>>>> dll_load[1508] #elif (defined ARM) >>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, >>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>> *** os/solaris/vm/os_solaris.cpp: >>>>> dll_load[1725] #elif (defined ARM) >>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, >>>> ARM >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>> store[164] #if !defined(ARM) && !defined(M68K) >>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) >>>>> add[178] #ifdef ARM >>>>> add_ptr[190] #ifdef ARM >>>>> xchg[230] #ifdef ARM >>>>> xchg_ptr[253] #ifdef ARM >>>>> cmpxchg[275] #ifdef ARM >>>>> cmpxchg_ptr[298] #ifdef ARM >>>>> >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>> add[172] #ifdef ARM >>>>> add_ptr[184] #ifdef ARM >>>>> xchg[224] #ifdef ARM >>>>> xchg_ptr[247] #ifdef ARM >>>>> cmpxchg[269] #ifdef ARM >>>>> cmpxchg_ptr[292] #ifdef ARM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>> (Parisc is gone, puh!). >>>>>>> We basically patch all the shared changes onto the sources after >>>>>>> getting them via our licensee channel. >>>>>>> I think you should fix your closed port not to re-use the names of the >>>>>>> main openJdk platforms! >>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to have >> to >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >>>>>> we worked with the Open port to ensure that shared code guarded by >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >> identify >>>>>> word-size agnostic code and we introduced ARM32 in a handful of >> places >>>>>> that needed it. And sometimes we have to be careful and ensure that >>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>> >>>>>> This has all been working quite nicely, as the include guards used, for >>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which >> are >>>>>> never >>>>>> defined at the same time (derived from >> HOTSPOT_TARGET_CPU_ARCH). >>>> But >>>>>> the >>>>>> current changes remove those unique defines and, before the >> HEADER_H >>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >> include >>>>>> guards, and that doesn't work as they are not mutually exclusive. >>>>>> >>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>> keeping them so they can be used as include guards (or other >> conditional >>>>>> code) when needed, and where the macros are not suitable. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> I have no idea what hardware is addressed by your closed ports, >>>>>>> nor how you merge sources. >>>>>>> Is there also a port that sets >>>>>>> -DTARGET_ARCH_arm >>>>>>> -DARM >>>>>>> -DARM32 >>>>>>> ? >>>>>>> >>>>>>> To fix this either you define >>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>> #define ARM64 >>>>>>> #endif >>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>> Then you replace all >>>>>>> #ifdef AARCH64 >>>>>>> by >>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>> or maybe it suffices altogether f you replace >>>>>>> #ifdef AARCH64 >>>>>>> by >>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>> >>>>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>>>> that you have a 32-bit port. Therefore we set up these macros >>>>>>> as on x86, where there is one for the arch (X86) and two for >> LP64/!LP64 >>>>>>> (IA32, AMD64). This allowed to separate code for the closed port >>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both >> (PPC). >>>>>>> But I don't think it is necessary to do any further changes now, >> assuming >>>>>>> my change works for you as I adapted it. So we're all set I guess! >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind >> of >>>>>>>>>> workaround is obscure - you have to know that the Open Aarch64 >>>> port >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open >> port >>>>>> use >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>> something >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>> And I'm uneasy that it is no more. How do you handle that? You >> have >>>> to >>>>>>>>> check every AARCH change by RedHat against your closed port? >>>>>>>> The sources for the two ports are distinct so the only place we have >> to >>>>>>>> have a convention is in shared code that has CPU specific stuff and in >>>>>>>> the build files. >>>>>>>> >>>>>>>> The open Aarch64 port sets (among others): >>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>> -DAARCH64 >>>>>>>> >>>>>>>> the closed port sets >>>>>>>> >>>>>>>> -DTARGET_ARCH_arm >>>>>>>> -DARM >>>>>>>> -DAARCH64 >>>>>>>> >>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >>>>>> Whenever >>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was referring >> to >>>>>> our >>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 >>>> port. >>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>> >>>>>>>> We need to keep a clear distinction. Using the combination of >> AARCH64 >>>>>>>> and ARM is not so clear. >>>>>>>> >>>>>>>> You could easily have similar issues with other port groups - eg ppc64 >>>>>>>> vs ppc32 vs ppcle. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I don't know about the closed stuff, but aarch came up recently, >> and >>>>>>>>> before that it sure was equivalent. And it still is the case for >> openJDK. >>>>>>>>> Below output is grepped out of the make//platform_ >> files >>>> in >>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined twice. >>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE >> - >>>>>>>> DAMD64 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE >> - >>>>>> DIA32 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >> DCC_INTERP >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - >>>> DZERO - >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any further >>>> issues, >>>>>>>>>> but the incremental changes look okay. >>>>>>>>>> >>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I added macros for C headers: >>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>> and fixed the other issues mentioned by David and Coleen in this >>>> new >>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>> at the same time. >>>>>>>>>>> >>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind >> of >>>>>>>>>> workaround is obscure - you have to know that the Open Aarch64 >>>> port >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open >> port >>>>>> use >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>> something >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be >> fixed >>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>>>>>>>>>> >>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for >> the >>>>>> ifdef >>>>>>>> is >>>>>>>>>> not >>>>>>>>>>>>> going to work for our closed ports, unless I change that value >> to >>>>>>>> match >>>>>>>>>>>>> the open naming scheme. But that in turn will lead to other >>>>>> problems >>>>>>>> as >>>>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. In >>>>>> general >>>>>>>> you >>>>>>>>>>>> can't just replace: >>>>>>>>>>>> >>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>> >>>>>>>>>>>> with >>>>>>>>>>>> >>>>>>>>>>>> #ifdef abc >>>>>>>>>>>> >>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our case >>>> ARM >>>>>>>> and >>>>>>>>>>>> AARCH64 are both defined and are both needed. In contrast >>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to >>>>>> represent >>>>>>>> the >>>>>>>>>>>> architecture in this context. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends >> .hpp >>>>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, >>>> that >>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used >>>> only >>>>>>>> once. >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to >> get >>>> is >>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need not >>>> be >>>>>>>>>> mutually >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to >> be >>>> an >>>>>> if- >>>>>>>>>> else >>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the >> closed >>>>>> part >>>>>>>> of >>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get >>>> both >>>>>>>>>> defined >>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >> understand >>>>>> what >>>>>>>>>> the >>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, >> as >>>> we >>>>>>>> are >>>>>>>>>> not >>>>>>>>>>>>>>> overriding it for our port - which I think is the current >> problem, >>>>>> but >>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; >>>>>> Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>> files. >>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and >>>>>> comments >>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch directory, >> but >>>> I >>>>>>>> don't >>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. >> (Sorry I >>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs to >>>> be >>>>>>>>>> changed >>>>>>>>>>>> on >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that has >>>> the >>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >> header >>>>>> files if >>>>>>>> I >>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches >>>> internally >>>>>> for >>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was a >>>> common >>>>>> file >>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this >>>> kind >>>>>> of >>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>>>>>>>>>>>> Actually I think the implementation should be moved to >>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >> elided >>>>>> here ?? >>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the >>>>>> umbrella >>>>>>>>>> header >>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends >> .hpp >>>>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, >>>> that >>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used >>>> only >>>>>>>> once. >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to >> get >>>> is >>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need not >>>> be >>>>>>>>>> mutually >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to >> be >>>> an >>>>>> if- >>>>>>>>>> else >>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is >> that >>>>>>>> coming >>>>>>>>>>>> from >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>> WINDOWS >>>>>> in >>>>>>>> the >>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is defining >> - >>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but >> not >>>> in >>>>>> this >>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >> unused >>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>> ; >>>>>> Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>> hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's working >> on >>>> all >>>>>> the >>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the >> macros >>>> and >>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>> construction >>>>>>>> are >>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. >> But >>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses >> the >>>>>> very >>>>>>>>>> same >>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include >>>> that >>>>>> in >>>>>>>> the >>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine >>>> with >>>>>> your >>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that >> the >>>>>> linux=1 >>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should be >>>>>> upper >>>>>>>> case? >>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- >>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>> platform >>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> please take into account that these macros are >>>> only >>>>>>>> used >>>>>>>>>>>> within >>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs >> to >>>>>>>>>> understand >>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and >>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to >> spend >>>> days >>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my >>>> current >>>>>>>>>> progress >>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is >>>> adding >>>>>> the >>>>>>>>>>>>>>> #includes. >> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>> proposed >>>>>> in >>>>>>>> that >>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>> >> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email thread >> for >>>>>> me; it >>>>>>>>>> looks >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev >> but >>>>>> not >>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this >>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've >> only >>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait >>>> until >>>>>> the >>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------- >> ---- >>>> --- >>>>>> ---- >>>>>>>> --- >>>>>>>>>> --- >>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing >>>> #defines >>>>>>>> that >>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: >>>> linux=1, >>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the leading >>>>>>>> underscore >>>>>>>>>>>> part >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>> 68 - >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>> >> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >> instead >>>> of >>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are >>>> defined, >>>>>> but >>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>> underscore >>>>>>>>>>>> followed >>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >> pattern >>>>>> for >>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase >> for >>>>>> the >>>>>>>>>> macro >>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------- >> ---- >>>> --- >>>>>> ---- >>>>>>>> --- >>>>>>>>>> --- >>>>>>>>>>>> -- From david.holmes at oracle.com Thu Jul 21 03:25:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2016 13:25:51 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> Message-ID: <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > Hi > > New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.04/ > > It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in CompileJvm.gmk > and reverts the change to the aarch define in vmStructs_jvmci.cpp. I documented > what I learned about the platform defines in macros.hpp. Thanks - much appreciated. Other than Coleen's typo (well spotted!) and the lingering _32 the only nit I have left is a handful of copyright updates: src/cpu/x86/vm/register_definitions_x86.cpp: src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: src/share/vm/runtime/semaphore.hpp: src/cpu/ppc/vm/stubRoutines_ppc.hpp: src/cpu/ppc/vm/templateTable_ppc.hpp Then all we need is confirmation that all the open platforms that Oracle doesn't also build (aarch64 and Zero) build and run successfully after this change. I will sponsor this (in case that wasn't clear) but may have to delay it until after we sync up the hs forest with the CPU changes now in jdk9/dev. I will rebase and handle any merging if needed. Thanks, David ----- > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. Juli 2016 12:05 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> OK, to get this through I will add >>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>> and revert this one and only place it needs to be used in the >> vmStructs_jvmci.cpp. >> >> Thanks. >> >>> For the records, openJdk aarch64 has a C1 port. And yes, such cleanups >> should >>> not be in this change. >> >> I did not know they had a 64-bit C1 - interesting. >> >>> >>> Thanks for doing the closed changes! >> >> You're welcome. >> >> Cheers, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> Hi Goetz, >>>> >>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> that's great what you are saying and just the design I would expect! >>>>>> We did not want to have to >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >>>>>> we worked with the Open port to ensure that shared code guarded by >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >> identify >>>>>> word-size agnostic code and we introduced ARM32 in a handful of >> places >>>>>> that needed it. And sometimes we have to be careful and ensure that >>>>>> ifdef chains check AARCH64 before they check ARM. >>>>> >>>>> I think as a consequence the open AARCH port should define ARM, too. >>>> >>>> I would not want to do this and certainly not as part of this change. >>>> If/when the Aarch32 port arrives we may have to revisit this, but not >>>> right now, please. >>>> >>>>> I checked the occurrences and only see three places where this would >> have >>>>> an effect and would have to be fixed somehow: >>>>> >>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>> [610] #if defined(AARCH64) && !defined(ARM) >>>>> ==> Would this break the closed port if defined? >>>> >>>> Yes - it refers to specific piece of code in the open aarch64 sources. >>>> >>>>> (This is the only place where TARGET_ARCH_aarch64 was used) >>>>> >>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) >>>>> ==> Would this break the open port if defined? >>>>> >>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>> [1154] #ifdef ARM >>>>> ==> Would this break the open port if defined? >>>> >>>> I don't think the open port has C1 so it would ignore the above files >>>> anyway. >>>> >>>>> All the cases below are pointless. >>>>> >>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>> keeping them so they can be used as include guards (or other >> conditional >>>>>> code) when needed, and where the macros are not suitable. >>>>> I think it's quite misleading to have two defines that are 99% equivalent. >>>>> If we really need a special case here, you should define -DARM_CLOSED >>>>> or the like in your closed port. Such a name would make clear what's the >>>>> issue. At least, only your closed port has this problem. >>>> >>>> I really do not want to make any changes to this - ignoring the include >>>> macro changes everything we have is working perfectly fine just the way >>>> the defines are. So I don't want to see this change potentially break >>>> that through incidental changes. >>>> >>>> I do not see having the following is a big issue: >>>> >>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>> >>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>> TARGET_ARCH_arm to mean whatever the owners of that define intend >> it to >>>> mean. It certainly is a lot better than interpreting what the >>>> combinations of AARCH64 and ARM mean. Keeping this removes the >> need to >>>> perform some of the changes as noted above. >>>> >>>> I'm preparing the review of the internal changes we need to accompany >> this. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> These should not break the open port if ARM gets defined, or can be >> fixed >>>> easily. >>>>> --------------------------------------------------------- >>>>> >>>>> *** share/vm/c1/c1_LIR.cpp: >>>>> print[1519] #elif defined(ARM) >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>> >>>>> *** os/linux/vm/os_linux.cpp: >>>>> dll_load[1796] #elif (defined ARM) >>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>> >>>>> *** share/vm/opto/matcher.cpp: >>>>> init_first_stack_mask[558] #ifdef ARM >>>>> ==> Should be ARM32 (Is under !LP64). >>>>> >>>>> *** share/vm/c1/c1_LIR.cpp: >>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) >>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) >>>>> ==> Just an assertion. Will just relax the check if defined in open >> AARCH64. >>>>> But maybe should be guarded by __SOFTFP__. >>>>> [70] #if defined(ARM) || defined(AARCH64) || >>>> defined(PPC64) >>>>> ==> Fine: || >>>>> >>>>> *** share/vm/c1/c1_LIR.hpp: >>>>> [447] #if defined(SPARC) || defined(ARM) || >>>> defined(PPC) || defined(AARCH64) >>>>> [537] #if defined(X86) || defined(ARM) || >>>> defined(AARCH64) >>>>> ==> Fine: || >>>>> >>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>> defined[162] #if defined(IA32) || defined(AMD64) || >>>> defined(ARM) >>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>> [1358] #if defined(IA32) || defined(AMD64) || >>>> defined(ARM) >>>>> ==> Just defines a method which would be unused, should be fine. >>>>> >>>>> >>>>> These are in code not used in the open AARCH64 port: >>>>> -------------------------------------------------- >>>>> >>>>> *** os/bsd/vm/os_bsd.cpp: >>>>> [215] #elif defined(ARM) >>>>> >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>> [102] #ifdef ARM >>>>> >>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>> [31] #ifdef ARM >>>>> >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>> [102] #ifdef ARM >>>>> >>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>> [31] #ifdef ARM >>>>> >>>>> *** share/vm/utilities/macros.hpp: >>>>> [434] #ifdef ARM >>>>> >>>>> *** os/bsd/vm/os_bsd.cpp: >>>>> dll_load[1508] #elif (defined ARM) >>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, >>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>> >>>>> *** os/solaris/vm/os_solaris.cpp: >>>>> dll_load[1725] #elif (defined ARM) >>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, ARM, >>>> ARM >>>>> >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>> store[164] #if !defined(ARM) && !defined(M68K) >>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) >>>>> add[178] #ifdef ARM >>>>> add_ptr[190] #ifdef ARM >>>>> xchg[230] #ifdef ARM >>>>> xchg_ptr[253] #ifdef ARM >>>>> cmpxchg[275] #ifdef ARM >>>>> cmpxchg_ptr[298] #ifdef ARM >>>>> >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>> add[172] #ifdef ARM >>>>> add_ptr[184] #ifdef ARM >>>>> xchg[224] #ifdef ARM >>>>> xchg_ptr[247] #ifdef ARM >>>>> cmpxchg[269] #ifdef ARM >>>>> cmpxchg_ptr[292] #ifdef ARM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>> (Parisc is gone, puh!). >>>>>>> We basically patch all the shared changes onto the sources after >>>>>>> getting them via our licensee channel. >>>>>>> I think you should fix your closed port not to re-use the names of the >>>>>>> main openJdk platforms! >>>>>> >>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to have >> to >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" so >>>>>> we worked with the Open port to ensure that shared code guarded by >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >> identify >>>>>> word-size agnostic code and we introduced ARM32 in a handful of >> places >>>>>> that needed it. And sometimes we have to be careful and ensure that >>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>> >>>>>> This has all been working quite nicely, as the include guards used, for >>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which >> are >>>>>> never >>>>>> defined at the same time (derived from >> HOTSPOT_TARGET_CPU_ARCH). >>>> But >>>>>> the >>>>>> current changes remove those unique defines and, before the >> HEADER_H >>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >> include >>>>>> guards, and that doesn't work as they are not mutually exclusive. >>>>>> >>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>> keeping them so they can be used as include guards (or other >> conditional >>>>>> code) when needed, and where the macros are not suitable. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> I have no idea what hardware is addressed by your closed ports, >>>>>>> nor how you merge sources. >>>>>>> Is there also a port that sets >>>>>>> -DTARGET_ARCH_arm >>>>>>> -DARM >>>>>>> -DARM32 >>>>>>> ? >>>>>>> >>>>>>> To fix this either you define >>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>> #define ARM64 >>>>>>> #endif >>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>> Then you replace all >>>>>>> #ifdef AARCH64 >>>>>>> by >>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>> or maybe it suffices altogether f you replace >>>>>>> #ifdef AARCH64 >>>>>>> by >>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>> >>>>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>>>> that you have a 32-bit port. Therefore we set up these macros >>>>>>> as on x86, where there is one for the arch (X86) and two for >> LP64/!LP64 >>>>>>> (IA32, AMD64). This allowed to separate code for the closed port >>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both >> (PPC). >>>>>>> >>>>>>> But I don't think it is necessary to do any further changes now, >> assuming >>>>>>> my change works for you as I adapted it. So we're all set I guess! >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind >> of >>>>>>>>>> workaround is obscure - you have to know that the Open Aarch64 >>>> port >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open >> port >>>>>> use >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>> something >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>> >>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>> And I'm uneasy that it is no more. How do you handle that? You >> have >>>> to >>>>>>>>> check every AARCH change by RedHat against your closed port? >>>>>>>> >>>>>>>> The sources for the two ports are distinct so the only place we have >> to >>>>>>>> have a convention is in shared code that has CPU specific stuff and in >>>>>>>> the build files. >>>>>>>> >>>>>>>> The open Aarch64 port sets (among others): >>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>> -DAARCH64 >>>>>>>> >>>>>>>> the closed port sets >>>>>>>> >>>>>>>> -DTARGET_ARCH_arm >>>>>>>> -DARM >>>>>>>> -DAARCH64 >>>>>>>> >>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >>>>>> Whenever >>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was referring >> to >>>>>> our >>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open Aarch64 >>>> port. >>>>>>>> >>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>> >>>>>>>> We need to keep a clear distinction. Using the combination of >> AARCH64 >>>>>>>> and ARM is not so clear. >>>>>>>> >>>>>>>> You could easily have similar issues with other port groups - eg ppc64 >>>>>>>> vs ppc32 vs ppcle. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I don't know about the closed stuff, but aarch came up recently, >> and >>>>>>>>> before that it sure was equivalent. And it still is the case for >> openJDK. >>>>>>>>> >>>>>>>>> Below output is grepped out of the make//platform_ >> files >>>> in >>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined twice. >>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE >> - >>>>>>>> DAMD64 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -D_GNU_SOURCE >> - >>>>>> DIA32 >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >> DCC_INTERP >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - >>>> DZERO - >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any further >>>> issues, >>>>>>>>>> but the incremental changes look okay. >>>>>>>>>> >>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I added macros for C headers: >>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>> and fixed the other issues mentioned by David and Coleen in this >>>> new >>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>> at the same time. >>>>>>>>>>> >>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>> >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This kind >> of >>>>>>>>>> workaround is obscure - you have to know that the Open Aarch64 >>>> port >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open >> port >>>>>> use >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>> something >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be >> fixed >>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>> >>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>>>>>>>>>> >>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value for >> the >>>>>> ifdef >>>>>>>> is >>>>>>>>>> not >>>>>>>>>>>>> going to work for our closed ports, unless I change that value >> to >>>>>>>> match >>>>>>>>>>>>> the open naming scheme. But that in turn will lead to other >>>>>> problems >>>>>>>> as >>>>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>>>> >>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. In >>>>>> general >>>>>>>> you >>>>>>>>>>>> can't just replace: >>>>>>>>>>>> >>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>> >>>>>>>>>>>> with >>>>>>>>>>>> >>>>>>>>>>>> #ifdef abc >>>>>>>>>>>> >>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our case >>>> ARM >>>>>>>> and >>>>>>>>>>>> AARCH64 are both defined and are both needed. In contrast >>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to >>>>>> represent >>>>>>>> the >>>>>>>>>>>> architecture in this context. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends >> .hpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, >>>> that >>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used >>>> only >>>>>>>> once. >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to >> get >>>> is >>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need not >>>> be >>>>>>>>>> mutually >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to >> be >>>> an >>>>>> if- >>>>>>>>>> else >>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the >> closed >>>>>> part >>>>>>>> of >>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we get >>>> both >>>>>>>>>> defined >>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >> understand >>>>>> what >>>>>>>>>> the >>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to be, >> as >>>> we >>>>>>>> are >>>>>>>>>> not >>>>>>>>>>>>>>> overriding it for our port - which I think is the current >> problem, >>>>>> but >>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; >>>>>> Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and >>>>>> comments >>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch directory, >> but >>>> I >>>>>>>> don't >>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. >> (Sorry I >>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs to >>>> be >>>>>>>>>> changed >>>>>>>>>>>> on >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that has >>>> the >>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >> header >>>>>> files if >>>>>>>> I >>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches >>>> internally >>>>>> for >>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not hold: >>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was a >>>> common >>>>>> file >>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid this >>>> kind >>>>>> of >>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in TARGET_SO... >>>>>>>>>>>>>>>>>> Actually I think the implementation should be moved to >>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >> elided >>>>>> here ?? >>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the >>>>>> umbrella >>>>>>>>>> header >>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends >> .hpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> can we not define a second form, eg CPU_HEADER_H, >>>> that >>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be used >>>> only >>>>>>>> once. >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it to >> get >>>> is >>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need not >>>> be >>>>>>>>>> mutually >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs to >> be >>>> an >>>>>> if- >>>>>>>>>> else >>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is >> that >>>>>>>> coming >>>>>>>>>>>> from >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>> WINDOWS >>>>>> in >>>>>>>> the >>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is defining >> - >>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, but >> not >>>> in >>>>>> this >>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >> unused >>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>> ; >>>>>> Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>> hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's working >> on >>>> all >>>>>> the >>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the >> macros >>>> and >>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>> construction >>>>>>>> are >>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in macros.hpp. >> But >>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses >> the >>>>>> very >>>>>>>>>> same >>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could include >>>> that >>>>>> in >>>>>>>> the >>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as fine >>>> with >>>>>> your >>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that >> the >>>>>> linux=1 >>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should be >>>>>> upper >>>>>>>> case? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; hotspot- >>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>> platform >>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, Goetz >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> please take into account that these macros are >>>> only >>>>>>>> used >>>>>>>>>>>> within >>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody needs >> to >>>>>>>>>> understand >>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp and >>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to >> spend >>>> days >>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my >>>> current >>>>>>>>>> progress >>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do is >>>> adding >>>>>> the >>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>> >> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>> proposed >>>>>> in >>>>>>>> that >>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>> >> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email thread >> for >>>>>> me; it >>>>>>>>>> looks >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler-dev >> but >>>>>> not >>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list this >>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've >> only >>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can wait >>>> until >>>>>> the >>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------- >> ---- >>>> --- >>>>>> ---- >>>>>>>> --- >>>>>>>>>> --- >>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing >>>> #defines >>>>>>>> that >>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: >>>> linux=1, >>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the leading >>>>>>>> underscore >>>>>>>>>>>> part >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>> >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the values. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>> >> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >> instead >>>> of >>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are >>>> defined, >>>>>> but >>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>> underscore >>>>>>>>>>>> followed >>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >> pattern >>>>>> for >>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use uppercase >> for >>>>>> the >>>>>>>>>> macro >>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------- >> ---- >>>> --- >>>>>> ---- >>>>>>>> --- >>>>>>>>>> --- >>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> From Alan.Bateman at oracle.com Thu Jul 21 07:25:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jul 2016 08:25:13 +0100 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: <90ad7800-db3b-cf7e-b2ab-1aca4105a570@oracle.com> On 20/07/2016 22:47, Coleen Phillimore wrote: > > > Why aren't addmods and limitmods allowed be specified more than once > on the command line and handled like the other ones? It's last one wins, typical for most options when repeated. I could imagine someone composing a command line with --add-modules coming from multiple sources, they logically merge/union, so maybe there is a case for that. However --limit-modules is niche and I don't think makes sense to attempt to merge. > > We should add an option -XX:+UseUnsafe to be a shortcut for this: > > --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED That may be useful for JDK tests but it makes it too easy to get to jdk.internal.misc.Unsafe. For usages outside of the JDK then I think they should continue to use sun.misc.Unsafe (JEP 260 etc.) and gradually reduce that over time as better approaches are available in the platform. -Alan From goetz.lindenmaier at sap.com Thu Jul 21 08:53:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Jul 2016 08:53:23 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <57f6eeeb-e107-574a-f36f-551cb5f16fd9@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <57f6eeeb-e107-574a-f36f-551cb5f16fd9@oracle.com> Message-ID: <44be944638d44d38b299c3f2220e8c83@DEWDFE13DE09.global.corp.sap> Hi Coleen, I fixed the two small issues, thanks for catching the type-O! About macroAssembler_inline.hpp: It was introduced to reduce the include cascades, which were in many files before. With the new includes, it's less necessary. But I still like the idea to have a file corresponding to the platform files in the /share tree, at least as long as it's included in shared files, see below. I think the zero file was there because zero had no macroAssembler_zero.inline.hpp, but all other macroAssembler_zero.inline.hpp bring assembler_zero.inline.hpp with them. Best regards, Goetz. src/share/vm/asm/assembler.cpp:#include "asm/macroAssembler.inline.hpp" src/share/vm/c1/c1_MacroAssembler.hpp:#include "asm/macroAssembler.inline.hpp" src/share/vm/interpreter/abstractInterpreter.cpp:#include "asm/macroAssembler.inline.hpp" src/share/vm/interpreter/interpreter.cpp:#include "asm/macroAssembler.inline.hpp" src/share/vm/opto/compile.cpp:#include "asm/macroAssembler.inline.hpp" src/share/vm/runtime/stubCodeGenerator.cpp:#include "asm/macroAssembler.inline.hpp" > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Donnerstag, 21. Juli 2016 04:31 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.04/src/cpu/aarch64/vm/vm_version_aarch64.cpp.udiff. > html > > This has a typo > > +#include OS_HEADER_INLCUDE(os) > > > If everything compiled, then do you really need this? > > http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.04/src/share/vm/asm/macroAssembler.inline.hpp.udiff > .html > > Strange that Zero included assembler_zero.hpp and the rest included > macroAssembler_.hpp You said that Zero builds after this change? > > > http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.04/src/cpu/x86/vm/stubRoutines_x86.hpp.udiff.html > > #endif // CPU_X86_VM_STUBROUTINES_X86_32_HPP > > > Can you fix this to match (ie remove _32)? > > Everything else looks great. Thank you! > > Coleen > > On 7/20/16 6:32 AM, Lindenmaier, Goetz wrote: > > Hi > > > > New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.04/ > > > > It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > CompileJvm.gmk > > and reverts the change to the aarch define in vmStructs_jvmci.cpp. I > documented > > what I learned about the platform defines in macros.hpp. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 20. Juli 2016 12:05 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> OK, to get this through I will add > >>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>> and revert this one and only place it needs to be used in the > >> vmStructs_jvmci.cpp. > >> > >> Thanks. > >> > >>> For the records, openJdk aarch64 has a C1 port. And yes, such cleanups > >> should > >>> not be in this change. > >> I did not know they had a 64-bit C1 - interesting. > >> > >>> Thanks for doing the closed changes! > >> You're welcome. > >> > >> Cheers, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> that's great what you are saying and just the design I would expect! > >>>>>> We did not want to have to > >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" > so > >>>>>> we worked with the Open port to ensure that shared code guarded > by > >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >> identify > >>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >> places > >>>>>> that needed it. And sometimes we have to be careful and ensure > that > >>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>> I think as a consequence the open AARCH port should define ARM, > too. > >>>> I would not want to do this and certainly not as part of this change. > >>>> If/when the Aarch32 port arrives we may have to revisit this, but not > >>>> right now, please. > >>>> > >>>>> I checked the occurrences and only see three places where this would > >> have > >>>>> an effect and would have to be fixed somehow: > >>>>> > >>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>> [610] #if defined(AARCH64) && !defined(ARM) > >>>>> ==> Would this break the closed port if defined? > >>>> Yes - it refers to specific piece of code in the open aarch64 sources. > >>>> > >>>>> (This is the only place where TARGET_ARCH_aarch64 was used) > >>>>> > >>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) > >>>>> ==> Would this break the open port if defined? > >>>>> > >>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>> [1154] #ifdef ARM > >>>>> ==> Would this break the open port if defined? > >>>> I don't think the open port has C1 so it would ignore the above files > >>>> anyway. > >>>> > >>>>> All the cases below are pointless. > >>>>> > >>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>> keeping them so they can be used as include guards (or other > >> conditional > >>>>>> code) when needed, and where the macros are not suitable. > >>>>> I think it's quite misleading to have two defines that are 99% > equivalent. > >>>>> If we really need a special case here, you should define - > DARM_CLOSED > >>>>> or the like in your closed port. Such a name would make clear what's > the > >>>>> issue. At least, only your closed port has this problem. > >>>> I really do not want to make any changes to this - ignoring the include > >>>> macro changes everything we have is working perfectly fine just the > way > >>>> the defines are. So I don't want to see this change potentially break > >>>> that through incidental changes. > >>>> > >>>> I do not see having the following is a big issue: > >>>> > >>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>> > >>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and > >>>> TARGET_ARCH_arm to mean whatever the owners of that define > intend > >> it to > >>>> mean. It certainly is a lot better than interpreting what the > >>>> combinations of AARCH64 and ARM mean. Keeping this removes the > >> need to > >>>> perform some of the changes as noted above. > >>>> > >>>> I'm preparing the review of the internal changes we need to > accompany > >> this. > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> These should not break the open port if ARM gets defined, or can be > >> fixed > >>>> easily. > >>>>> --------------------------------------------------------- > >>>>> > >>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>> print[1519] #elif defined(ARM) > >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>> > >>>>> *** os/linux/vm/os_linux.cpp: > >>>>> dll_load[1796] #elif (defined ARM) > >>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>> > >>>>> *** share/vm/opto/matcher.cpp: > >>>>> init_first_stack_mask[558] #ifdef ARM > >>>>> ==> Should be ARM32 (Is under !LP64). > >>>>> > >>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > >>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > >>>>> ==> Just an assertion. Will just relax the check if defined in open > >> AARCH64. > >>>>> But maybe should be guarded by __SOFTFP__. > >>>>> [70] #if defined(ARM) || defined(AARCH64) || > >>>> defined(PPC64) > >>>>> ==> Fine: || > >>>>> > >>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>> [447] #if defined(SPARC) || defined(ARM) || > >>>> defined(PPC) || defined(AARCH64) > >>>>> [537] #if defined(X86) || defined(ARM) || > >>>> defined(AARCH64) > >>>>> ==> Fine: || > >>>>> > >>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>> defined[162] #if defined(IA32) || defined(AMD64) || > >>>> defined(ARM) > >>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>> [1358] #if defined(IA32) || defined(AMD64) || > >>>> defined(ARM) > >>>>> ==> Just defines a method which would be unused, should be fine. > >>>>> > >>>>> > >>>>> These are in code not used in the open AARCH64 port: > >>>>> -------------------------------------------------- > >>>>> > >>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>> [215] #elif defined(ARM) > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>> [102] #ifdef ARM > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>> [31] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>> [102] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>> [31] #ifdef ARM > >>>>> > >>>>> *** share/vm/utilities/macros.hpp: > >>>>> [434] #ifdef ARM > >>>>> > >>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>> dll_load[1508] #elif (defined ARM) > >>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, > ARM, > >>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>> dll_load[1725] #elif (defined ARM) > >>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, > ARM, > >>>> ARM > >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>> store[164] #if !defined(ARM) && !defined(M68K) > >>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) > >>>>> add[178] #ifdef ARM > >>>>> add_ptr[190] #ifdef ARM > >>>>> xchg[230] #ifdef ARM > >>>>> xchg_ptr[253] #ifdef ARM > >>>>> cmpxchg[275] #ifdef ARM > >>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>> add[172] #ifdef ARM > >>>>> add_ptr[184] #ifdef ARM > >>>>> xchg[224] #ifdef ARM > >>>>> xchg_ptr[247] #ifdef ARM > >>>>> cmpxchg[269] #ifdef ARM > >>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. > >>>>>>> (Parisc is gone, puh!). > >>>>>>> We basically patch all the shared changes onto the sources after > >>>>>>> getting them via our licensee channel. > >>>>>>> I think you should fix your closed port not to re-use the names of > the > >>>>>>> main openJdk platforms! > >>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to > have > >> to > >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" > so > >>>>>> we worked with the Open port to ensure that shared code guarded > by > >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >> identify > >>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >> places > >>>>>> that needed it. And sometimes we have to be careful and ensure > that > >>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>> > >>>>>> This has all been working quite nicely, as the include guards used, for > >>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which > >> are > >>>>>> never > >>>>>> defined at the same time (derived from > >> HOTSPOT_TARGET_CPU_ARCH). > >>>> But > >>>>>> the > >>>>>> current changes remove those unique defines and, before the > >> HEADER_H > >>>>>> forms were introduced, tried to use simple AARCH64 and ARM as > >> include > >>>>>> guards, and that doesn't work as they are not mutually exclusive. > >>>>>> > >>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>> keeping them so they can be used as include guards (or other > >> conditional > >>>>>> code) when needed, and where the macros are not suitable. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> I have no idea what hardware is addressed by your closed ports, > >>>>>>> nor how you merge sources. > >>>>>>> Is there also a port that sets > >>>>>>> -DTARGET_ARCH_arm > >>>>>>> -DARM > >>>>>>> -DARM32 > >>>>>>> ? > >>>>>>> > >>>>>>> To fix this either you define > >>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>> #define ARM64 > >>>>>>> #endif > >>>>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>>>> Then you replace all > >>>>>>> #ifdef AARCH64 > >>>>>>> by > >>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>> or maybe it suffices altogether f you replace > >>>>>>> #ifdef AARCH64 > >>>>>>> by > >>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>> > >>>>>>> For ppc, when we did the port we knew (and that's all we knew) > >>>>>>> that you have a 32-bit port. Therefore we set up these macros > >>>>>>> as on x86, where there is one for the arch (X86) and two for > >> LP64/!LP64 > >>>>>>> (IA32, AMD64). This allowed to separate code for the closed port > >>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both > >> (PPC). > >>>>>>> But I don't think it is necessary to do any further changes now, > >> assuming > >>>>>>> my change works for you as I adapted it. So we're all set I guess! > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > kind > >> of > >>>>>>>>>> workaround is obscure - you have to know that the Open > Aarch64 > >>>> port > >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > >> port > >>>>>> use > >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>> something > >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>> And I'm uneasy that it is no more. How do you handle that? You > >> have > >>>> to > >>>>>>>>> check every AARCH change by RedHat against your closed port? > >>>>>>>> The sources for the two ports are distinct so the only place we > have > >> to > >>>>>>>> have a convention is in shared code that has CPU specific stuff and > in > >>>>>>>> the build files. > >>>>>>>> > >>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>> -DAARCH64 > >>>>>>>> > >>>>>>>> the closed port sets > >>>>>>>> > >>>>>>>> -DTARGET_ARCH_arm > >>>>>>>> -DARM > >>>>>>>> -DAARCH64 > >>>>>>>> > >>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. > >>>>>> Whenever > >>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was > referring > >> to > >>>>>> our > >>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open > Aarch64 > >>>> port. > >>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >>>>>>>> > >>>>>>>> We need to keep a clear distinction. Using the combination of > >> AARCH64 > >>>>>>>> and ARM is not so clear. > >>>>>>>> > >>>>>>>> You could easily have similar issues with other port groups - eg > ppc64 > >>>>>>>> vs ppc32 vs ppcle. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> I don't know about the closed stuff, but aarch came up recently, > >> and > >>>>>>>>> before that it sure was equivalent. And it still is the case for > >> openJDK. > >>>>>>>>> Below output is grepped out of the make//platform_ > >> files > >>>> in > >>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined > twice. > >>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > D_GNU_SOURCE > >> - > >>>>>>>> DAMD64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > D_GNU_SOURCE > >> - > >>>>>> DIA32 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - > >> DCC_INTERP > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - > >>>> DZERO - > >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > DAMD64 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any further > >>>> issues, > >>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>> > >>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>> and fixed the other issues mentioned by David and Coleen in > this > >>>> new > >>>>>>>>>> webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>> I also added comments that AARCH64 and ARM are defined > >>>>>>>>>>> at the same time. > >>>>>>>>>>> > >>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > kind > >> of > >>>>>>>>>> workaround is obscure - you have to know that the Open > Aarch64 > >>>> port > >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > >> port > >>>>>> use > >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>> something > >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >>>> Barrett > >>>>>>>>>>>> > >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be > >> fixed > >>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>>>>>>>>>> > >>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value > for > >> the > >>>>>> ifdef > >>>>>>>> is > >>>>>>>>>> not > >>>>>>>>>>>>> going to work for our closed ports, unless I change that > value > >> to > >>>>>>>> match > >>>>>>>>>>>>> the open naming scheme. But that in turn will lead to other > >>>>>> problems > >>>>>>>> as > >>>>>>>>>>>>> we also need that value the way it is currently defined. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. > In > >>>>>> general > >>>>>>>> you > >>>>>>>>>>>> can't just replace: > >>>>>>>>>>>> > >>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>> > >>>>>>>>>>>> with > >>>>>>>>>>>> > >>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>> > >>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our > case > >>>> ARM > >>>>>>>> and > >>>>>>>>>>>> AARCH64 are both defined and are both needed. In contrast > >>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to > >>>>>> represent > >>>>>>>> the > >>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > >> Kim > >>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >>>> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > >> .hpp > >>>>>>>>>>>>>>>>>>> can we not define a second form, eg > CPU_HEADER_H, > >>>> that > >>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > used > >>>> only > >>>>>>>> once. > >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it > to > >> get > >>>> is > >>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need > not > >>>> be > >>>>>>>>>> mutually > >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs > to > >> be > >>>> an > >>>>>> if- > >>>>>>>>>> else > >>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in > >>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the > >> closed > >>>>>> part > >>>>>>>> of > >>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we > get > >>>> both > >>>>>>>>>> defined > >>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to > >> understand > >>>>>> what > >>>>>>>>>> the > >>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to > be, > >> as > >>>> we > >>>>>>>> are > >>>>>>>>>> not > >>>>>>>>>>>>>>> overriding it for our port - which I think is the current > >> problem, > >>>>>> but > >>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>>> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; > >>>>>> Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and > >>>>>> comments > >>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch > directory, > >> but > >>>> I > >>>>>>>> don't > >>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. > >> (Sorry I > >>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs > to > >>>> be > >>>>>>>>>> changed > >>>>>>>>>>>> on > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that > has > >>>> the > >>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 > >> header > >>>>>> files if > >>>>>>>> I > >>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches > >>>> internally > >>>>>> for > >>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not > hold: > >>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was a > >>>> common > >>>>>> file > >>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid > this > >>>> kind > >>>>>> of > >>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in > TARGET_SO... > >>>>>>>>>>>>>>>>>> Actually I think the implementation should be moved > to > >>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be > >> elided > >>>>>> here ?? > >>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the > >>>>>> umbrella > >>>>>>>>>> header > >>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > >> .hpp > >>>>>>>>>>>>>>>>>>> can we not define a second form, eg > CPU_HEADER_H, > >>>> that > >>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > used > >>>> only > >>>>>>>> once. > >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it > to > >> get > >>>> is > >>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need > not > >>>> be > >>>>>>>>>> mutually > >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs > to > >> be > >>>> an > >>>>>> if- > >>>>>>>>>> else > >>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is > >> that > >>>>>>>> coming > >>>>>>>>>>>> from > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined > >>>> WINDOWS > >>>>>> in > >>>>>>>> the > >>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is > defining > >> - > >>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, > but > >> not > >>>> in > >>>>>> this > >>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the > >> unused > >>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>> ; > >>>>>> Kim > >>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>> hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>> platform > >>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's > working > >> on > >>>> all > >>>>>> the > >>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the > >> macros > >>>> and > >>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name > >>>>>> construction > >>>>>>>> are > >>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in > macros.hpp. > >> But > >>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses > >> the > >>>>>> very > >>>>>>>>>> same > >>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could > include > >>>> that > >>>>>> in > >>>>>>>> the > >>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as > fine > >>>> with > >>>>>> your > >>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that > >> the > >>>>>> linux=1 > >>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should > be > >>>>>> upper > >>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; > hotspot- > >>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>> platform > >>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, > Goetz > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> please take into account that these macros > are > >>>> only > >>>>>>>> used > >>>>>>>>>>>> within > >>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody > needs > >> to > >>>>>>>>>> understand > >>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp > and > >>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to > >> spend > >>>> days > >>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my > >>>> current > >>>>>>>>>> progress > >>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do > is > >>>> adding > >>>>>> the > >>>>>>>>>>>>>>> #includes. > >> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker > >>>> proposed > >>>>>> in > >>>>>>>> that > >>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>> > >> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email > thread > >> for > >>>>>> me; it > >>>>>>>>>> looks > >>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler- > dev > >> but > >>>>>> not > >>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list > this > >>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've > >> only > >>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can > wait > >>>> until > >>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> ---- > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing > >>>> #defines > >>>>>>>> that > >>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: > >>>> linux=1, > >>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the > leading > >>>>>>>> underscore > >>>>>>>>>>>> part > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>> 68 - > >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the > values. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > >> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets > >> instead > >>>> of > >>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are > >>>> defined, > >>>>>> but > >>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that > >>>> underscore > >>>>>>>>>>>> followed > >>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word > >> pattern > >>>>>> for > >>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use > uppercase > >> for > >>>>>> the > >>>>>>>>>> macro > >>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> ---- > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> -- From goetz.lindenmaier at sap.com Thu Jul 21 09:27:45 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Jul 2016 09:27:45 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> Message-ID: Hi David, Copyright of register_definitions_x86.cpp is already fixed in hs-comp, I'll skip it to avoid merges. I fixed the others. New webrevs, also with Coleens fixes: http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ I also did another zero build configured as follows: --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm-variants=zero on linuxx86_64. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 21. Juli 2016 05:26 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > > Hi > > > > New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.04/ > > > > It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > CompileJvm.gmk > > and reverts the change to the aarch define in vmStructs_jvmci.cpp. I > documented > > what I learned about the platform defines in macros.hpp. > > Thanks - much appreciated. Other than Coleen's typo (well spotted!) and > the lingering _32 the only nit I have left is a handful of copyright > updates: > > src/cpu/x86/vm/register_definitions_x86.cpp: > src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > src/share/vm/runtime/semaphore.hpp: > src/cpu/ppc/vm/stubRoutines_ppc.hpp: > src/cpu/ppc/vm/templateTable_ppc.hpp > > Then all we need is confirmation that all the open platforms that Oracle > doesn't also build (aarch64 and Zero) build and run successfully after > this change. > > I will sponsor this (in case that wasn't clear) but may have to delay it > until after we sync up the hs forest with the CPU changes now in > jdk9/dev. I will rebase and handle any merging if needed. > > Thanks, > David > ----- > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 20. Juli 2016 12:05 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> OK, to get this through I will add > >>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>> and revert this one and only place it needs to be used in the > >> vmStructs_jvmci.cpp. > >> > >> Thanks. > >> > >>> For the records, openJdk aarch64 has a C1 port. And yes, such cleanups > >> should > >>> not be in this change. > >> > >> I did not know they had a 64-bit C1 - interesting. > >> > >>> > >>> Thanks for doing the closed changes! > >> > >> You're welcome. > >> > >> Cheers, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> that's great what you are saying and just the design I would expect! > >>>>>> We did not want to have to > >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" > so > >>>>>> we worked with the Open port to ensure that shared code guarded > by > >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >> identify > >>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >> places > >>>>>> that needed it. And sometimes we have to be careful and ensure > that > >>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>> > >>>>> I think as a consequence the open AARCH port should define ARM, > too. > >>>> > >>>> I would not want to do this and certainly not as part of this change. > >>>> If/when the Aarch32 port arrives we may have to revisit this, but not > >>>> right now, please. > >>>> > >>>>> I checked the occurrences and only see three places where this would > >> have > >>>>> an effect and would have to be fixed somehow: > >>>>> > >>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>> [610] #if defined(AARCH64) && !defined(ARM) > >>>>> ==> Would this break the closed port if defined? > >>>> > >>>> Yes - it refers to specific piece of code in the open aarch64 sources. > >>>> > >>>>> (This is the only place where TARGET_ARCH_aarch64 was used) > >>>>> > >>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) > >>>>> ==> Would this break the open port if defined? > >>>>> > >>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>> [1154] #ifdef ARM > >>>>> ==> Would this break the open port if defined? > >>>> > >>>> I don't think the open port has C1 so it would ignore the above files > >>>> anyway. > >>>> > >>>>> All the cases below are pointless. > >>>>> > >>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>> keeping them so they can be used as include guards (or other > >> conditional > >>>>>> code) when needed, and where the macros are not suitable. > >>>>> I think it's quite misleading to have two defines that are 99% > equivalent. > >>>>> If we really need a special case here, you should define - > DARM_CLOSED > >>>>> or the like in your closed port. Such a name would make clear what's > the > >>>>> issue. At least, only your closed port has this problem. > >>>> > >>>> I really do not want to make any changes to this - ignoring the include > >>>> macro changes everything we have is working perfectly fine just the > way > >>>> the defines are. So I don't want to see this change potentially break > >>>> that through incidental changes. > >>>> > >>>> I do not see having the following is a big issue: > >>>> > >>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>> > >>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and > >>>> TARGET_ARCH_arm to mean whatever the owners of that define > intend > >> it to > >>>> mean. It certainly is a lot better than interpreting what the > >>>> combinations of AARCH64 and ARM mean. Keeping this removes the > >> need to > >>>> perform some of the changes as noted above. > >>>> > >>>> I'm preparing the review of the internal changes we need to > accompany > >> this. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> These should not break the open port if ARM gets defined, or can be > >> fixed > >>>> easily. > >>>>> --------------------------------------------------------- > >>>>> > >>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>> print[1519] #elif defined(ARM) > >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>> > >>>>> *** os/linux/vm/os_linux.cpp: > >>>>> dll_load[1796] #elif (defined ARM) > >>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>> > >>>>> *** share/vm/opto/matcher.cpp: > >>>>> init_first_stack_mask[558] #ifdef ARM > >>>>> ==> Should be ARM32 (Is under !LP64). > >>>>> > >>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > >>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > >>>>> ==> Just an assertion. Will just relax the check if defined in open > >> AARCH64. > >>>>> But maybe should be guarded by __SOFTFP__. > >>>>> [70] #if defined(ARM) || defined(AARCH64) || > >>>> defined(PPC64) > >>>>> ==> Fine: || > >>>>> > >>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>> [447] #if defined(SPARC) || defined(ARM) || > >>>> defined(PPC) || defined(AARCH64) > >>>>> [537] #if defined(X86) || defined(ARM) || > >>>> defined(AARCH64) > >>>>> ==> Fine: || > >>>>> > >>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>> defined[162] #if defined(IA32) || defined(AMD64) || > >>>> defined(ARM) > >>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>> [1358] #if defined(IA32) || defined(AMD64) || > >>>> defined(ARM) > >>>>> ==> Just defines a method which would be unused, should be fine. > >>>>> > >>>>> > >>>>> These are in code not used in the open AARCH64 port: > >>>>> -------------------------------------------------- > >>>>> > >>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>> [215] #elif defined(ARM) > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>> [102] #ifdef ARM > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>> [31] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>> [102] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>> [31] #ifdef ARM > >>>>> > >>>>> *** share/vm/utilities/macros.hpp: > >>>>> [434] #ifdef ARM > >>>>> > >>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>> dll_load[1508] #elif (defined ARM) > >>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, > ARM, > >>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>> > >>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>> dll_load[1725] #elif (defined ARM) > >>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, > ARM, > >>>> ARM > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>> store[164] #if !defined(ARM) && !defined(M68K) > >>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) > >>>>> add[178] #ifdef ARM > >>>>> add_ptr[190] #ifdef ARM > >>>>> xchg[230] #ifdef ARM > >>>>> xchg_ptr[253] #ifdef ARM > >>>>> cmpxchg[275] #ifdef ARM > >>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>> add[172] #ifdef ARM > >>>>> add_ptr[184] #ifdef ARM > >>>>> xchg[224] #ifdef ARM > >>>>> xchg_ptr[247] #ifdef ARM > >>>>> cmpxchg[269] #ifdef ARM > >>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. > >>>>>>> (Parisc is gone, puh!). > >>>>>>> We basically patch all the shared changes onto the sources after > >>>>>>> getting them via our licensee channel. > >>>>>>> I think you should fix your closed port not to re-use the names of > the > >>>>>>> main openJdk platforms! > >>>>>> > >>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to > have > >> to > >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" > so > >>>>>> we worked with the Open port to ensure that shared code guarded > by > >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >> identify > >>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >> places > >>>>>> that needed it. And sometimes we have to be careful and ensure > that > >>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>> > >>>>>> This has all been working quite nicely, as the include guards used, for > >>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which > >> are > >>>>>> never > >>>>>> defined at the same time (derived from > >> HOTSPOT_TARGET_CPU_ARCH). > >>>> But > >>>>>> the > >>>>>> current changes remove those unique defines and, before the > >> HEADER_H > >>>>>> forms were introduced, tried to use simple AARCH64 and ARM as > >> include > >>>>>> guards, and that doesn't work as they are not mutually exclusive. > >>>>>> > >>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>> keeping them so they can be used as include guards (or other > >> conditional > >>>>>> code) when needed, and where the macros are not suitable. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> I have no idea what hardware is addressed by your closed ports, > >>>>>>> nor how you merge sources. > >>>>>>> Is there also a port that sets > >>>>>>> -DTARGET_ARCH_arm > >>>>>>> -DARM > >>>>>>> -DARM32 > >>>>>>> ? > >>>>>>> > >>>>>>> To fix this either you define > >>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>> #define ARM64 > >>>>>>> #endif > >>>>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>>>> Then you replace all > >>>>>>> #ifdef AARCH64 > >>>>>>> by > >>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>> or maybe it suffices altogether f you replace > >>>>>>> #ifdef AARCH64 > >>>>>>> by > >>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>> > >>>>>>> For ppc, when we did the port we knew (and that's all we knew) > >>>>>>> that you have a 32-bit port. Therefore we set up these macros > >>>>>>> as on x86, where there is one for the arch (X86) and two for > >> LP64/!LP64 > >>>>>>> (IA32, AMD64). This allowed to separate code for the closed port > >>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both > >> (PPC). > >>>>>>> > >>>>>>> But I don't think it is necessary to do any further changes now, > >> assuming > >>>>>>> my change works for you as I adapted it. So we're all set I guess! > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > kind > >> of > >>>>>>>>>> workaround is obscure - you have to know that the Open > Aarch64 > >>>> port > >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > >> port > >>>>>> use > >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>> something > >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>> > >>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>> And I'm uneasy that it is no more. How do you handle that? You > >> have > >>>> to > >>>>>>>>> check every AARCH change by RedHat against your closed port? > >>>>>>>> > >>>>>>>> The sources for the two ports are distinct so the only place we > have > >> to > >>>>>>>> have a convention is in shared code that has CPU specific stuff and > in > >>>>>>>> the build files. > >>>>>>>> > >>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>> -DAARCH64 > >>>>>>>> > >>>>>>>> the closed port sets > >>>>>>>> > >>>>>>>> -DTARGET_ARCH_arm > >>>>>>>> -DARM > >>>>>>>> -DAARCH64 > >>>>>>>> > >>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. > >>>>>> Whenever > >>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was > referring > >> to > >>>>>> our > >>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open > Aarch64 > >>>> port. > >>>>>>>> > >>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >>>>>>>> > >>>>>>>> We need to keep a clear distinction. Using the combination of > >> AARCH64 > >>>>>>>> and ARM is not so clear. > >>>>>>>> > >>>>>>>> You could easily have similar issues with other port groups - eg > ppc64 > >>>>>>>> vs ppc32 vs ppcle. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> I don't know about the closed stuff, but aarch came up recently, > >> and > >>>>>>>>> before that it sure was equivalent. And it still is the case for > >> openJDK. > >>>>>>>>> > >>>>>>>>> Below output is grepped out of the make//platform_ > >> files > >>>> in > >>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined > twice. > >>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > D_GNU_SOURCE > >> - > >>>>>>>> DAMD64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > D_GNU_SOURCE > >> - > >>>>>> DIA32 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - > >> DCC_INTERP > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - > >>>> DZERO - > >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > DAMD64 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any further > >>>> issues, > >>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>> > >>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>> and fixed the other issues mentioned by David and Coleen in > this > >>>> new > >>>>>>>>>> webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>> > >>>>>>>>>>> I also added comments that AARCH64 and ARM are defined > >>>>>>>>>>> at the same time. > >>>>>>>>>>> > >>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>> > >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > kind > >> of > >>>>>>>>>> workaround is obscure - you have to know that the Open > Aarch64 > >>>> port > >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > >> port > >>>>>> use > >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>> something > >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >>>> Barrett > >>>>>>>>>>>> > >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be > >> fixed > >>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>>>>>>>>>> > >>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value > for > >> the > >>>>>> ifdef > >>>>>>>> is > >>>>>>>>>> not > >>>>>>>>>>>>> going to work for our closed ports, unless I change that > value > >> to > >>>>>>>> match > >>>>>>>>>>>>> the open naming scheme. But that in turn will lead to other > >>>>>> problems > >>>>>>>> as > >>>>>>>>>>>>> we also need that value the way it is currently defined. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>>>>>> > >>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. > In > >>>>>> general > >>>>>>>> you > >>>>>>>>>>>> can't just replace: > >>>>>>>>>>>> > >>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>> > >>>>>>>>>>>> with > >>>>>>>>>>>> > >>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>> > >>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our > case > >>>> ARM > >>>>>>>> and > >>>>>>>>>>>> AARCH64 are both defined and are both needed. In contrast > >>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to > >>>>>> represent > >>>>>>>> the > >>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > >> Kim > >>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >>>> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > >> .hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> can we not define a second form, eg > CPU_HEADER_H, > >>>> that > >>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > used > >>>> only > >>>>>>>> once. > >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it > to > >> get > >>>> is > >>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need > not > >>>> be > >>>>>>>>>> mutually > >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs > to > >> be > >>>> an > >>>>>> if- > >>>>>>>>>> else > >>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in > >>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the > >> closed > >>>>>> part > >>>>>>>> of > >>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we > get > >>>> both > >>>>>>>>>> defined > >>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to > >> understand > >>>>>> what > >>>>>>>>>> the > >>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to > be, > >> as > >>>> we > >>>>>>>> are > >>>>>>>>>> not > >>>>>>>>>>>>>>> overriding it for our port - which I think is the current > >> problem, > >>>>>> but > >>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>>> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; > >>>>>> Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and > >>>>>> comments > >>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch > directory, > >> but > >>>> I > >>>>>>>> don't > >>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. > >> (Sorry I > >>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs > to > >>>> be > >>>>>>>>>> changed > >>>>>>>>>>>> on > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that > has > >>>> the > >>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 > >> header > >>>>>> files if > >>>>>>>> I > >>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches > >>>> internally > >>>>>> for > >>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not > hold: > >>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was a > >>>> common > >>>>>> file > >>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid > this > >>>> kind > >>>>>> of > >>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in > TARGET_SO... > >>>>>>>>>>>>>>>>>> Actually I think the implementation should be moved > to > >>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be > >> elided > >>>>>> here ?? > >>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the > >>>>>> umbrella > >>>>>>>>>> header > >>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > >> .hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> can we not define a second form, eg > CPU_HEADER_H, > >>>> that > >>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > used > >>>> only > >>>>>>>> once. > >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it > to > >> get > >>>> is > >>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need > not > >>>> be > >>>>>>>>>> mutually > >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs > to > >> be > >>>> an > >>>>>> if- > >>>>>>>>>> else > >>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is > >> that > >>>>>>>> coming > >>>>>>>>>>>> from > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined > >>>> WINDOWS > >>>>>> in > >>>>>>>> the > >>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is > defining > >> - > >>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, > but > >> not > >>>> in > >>>>>> this > >>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the > >> unused > >>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>> ; > >>>>>> Kim > >>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>> hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>> platform > >>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's > working > >> on > >>>> all > >>>>>> the > >>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the > >> macros > >>>> and > >>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name > >>>>>> construction > >>>>>>>> are > >>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in > macros.hpp. > >> But > >>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses > >> the > >>>>>> very > >>>>>>>>>> same > >>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could > include > >>>> that > >>>>>> in > >>>>>>>> the > >>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as > fine > >>>> with > >>>>>> your > >>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that > >> the > >>>>>> linux=1 > >>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should > be > >>>>>> upper > >>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; > hotspot- > >>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>> platform > >>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, > Goetz > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> please take into account that these macros > are > >>>> only > >>>>>>>> used > >>>>>>>>>>>> within > >>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody > needs > >> to > >>>>>>>>>> understand > >>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp > and > >>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to > >> spend > >>>> days > >>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my > >>>> current > >>>>>>>>>> progress > >>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do > is > >>>> adding > >>>>>> the > >>>>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>>>> > >> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker > >>>> proposed > >>>>>> in > >>>>>>>> that > >>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>> > >> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email > thread > >> for > >>>>>> me; it > >>>>>>>>>> looks > >>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler- > dev > >> but > >>>>>> not > >>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list > this > >>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've > >> only > >>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can > wait > >>>> until > >>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> ---- > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing > >>>> #defines > >>>>>>>> that > >>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: > >>>> linux=1, > >>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the > leading > >>>>>>>> underscore > >>>>>>>>>>>> part > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>>>> > >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the > values. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > >> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets > >> instead > >>>> of > >>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are > >>>> defined, > >>>>>> but > >>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that > >>>> underscore > >>>>>>>>>>>> followed > >>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word > >> pattern > >>>>>> for > >>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use > uppercase > >> for > >>>>>> the > >>>>>>>>>> macro > >>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> ---- > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Thu Jul 21 09:32:43 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Jul 2016 09:32:43 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <563032699332485f9e57de827453d8ad@DEWDFE13DE09.global.corp.sap> <294c5770-2771-5969-3859-b6d8ea832989@oracle.com> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> Message-ID: <2160f712c9dc41538fb6ad607f8fc98a@DEWDFE13DE09.global.corp.sap> Hi, could someone at RedHat (or anybody who can build aarch64) please verify this change on aarch64? http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ Thanks! Goetz > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 21. Juli 2016 05:26 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > > Hi > > > > New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.04/ > > > > It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > CompileJvm.gmk > > and reverts the change to the aarch define in vmStructs_jvmci.cpp. I > documented > > what I learned about the platform defines in macros.hpp. > > Thanks - much appreciated. Other than Coleen's typo (well spotted!) and > the lingering _32 the only nit I have left is a handful of copyright > updates: > > src/cpu/x86/vm/register_definitions_x86.cpp: > src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > src/share/vm/runtime/semaphore.hpp: > src/cpu/ppc/vm/stubRoutines_ppc.hpp: > src/cpu/ppc/vm/templateTable_ppc.hpp > > Then all we need is confirmation that all the open platforms that Oracle > doesn't also build (aarch64 and Zero) build and run successfully after > this change. > > I will sponsor this (in case that wasn't clear) but may have to delay it > until after we sync up the hs forest with the CPU changes now in > jdk9/dev. I will rebase and handle any merging if needed. > > Thanks, > David > ----- > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 20. Juli 2016 12:05 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> OK, to get this through I will add > >>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>> and revert this one and only place it needs to be used in the > >> vmStructs_jvmci.cpp. > >> > >> Thanks. > >> > >>> For the records, openJdk aarch64 has a C1 port. And yes, such cleanups > >> should > >>> not be in this change. > >> > >> I did not know they had a 64-bit C1 - interesting. > >> > >>> > >>> Thanks for doing the closed changes! > >> > >> You're welcome. > >> > >> Cheers, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> that's great what you are saying and just the design I would expect! > >>>>>> We did not want to have to > >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" > so > >>>>>> we worked with the Open port to ensure that shared code guarded > by > >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >> identify > >>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >> places > >>>>>> that needed it. And sometimes we have to be careful and ensure > that > >>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>> > >>>>> I think as a consequence the open AARCH port should define ARM, > too. > >>>> > >>>> I would not want to do this and certainly not as part of this change. > >>>> If/when the Aarch32 port arrives we may have to revisit this, but not > >>>> right now, please. > >>>> > >>>>> I checked the occurrences and only see three places where this would > >> have > >>>>> an effect and would have to be fixed somehow: > >>>>> > >>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>> [610] #if defined(AARCH64) && !defined(ARM) > >>>>> ==> Would this break the closed port if defined? > >>>> > >>>> Yes - it refers to specific piece of code in the open aarch64 sources. > >>>> > >>>>> (This is the only place where TARGET_ARCH_aarch64 was used) > >>>>> > >>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) > >>>>> ==> Would this break the open port if defined? > >>>>> > >>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>> [1154] #ifdef ARM > >>>>> ==> Would this break the open port if defined? > >>>> > >>>> I don't think the open port has C1 so it would ignore the above files > >>>> anyway. > >>>> > >>>>> All the cases below are pointless. > >>>>> > >>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>> keeping them so they can be used as include guards (or other > >> conditional > >>>>>> code) when needed, and where the macros are not suitable. > >>>>> I think it's quite misleading to have two defines that are 99% > equivalent. > >>>>> If we really need a special case here, you should define - > DARM_CLOSED > >>>>> or the like in your closed port. Such a name would make clear what's > the > >>>>> issue. At least, only your closed port has this problem. > >>>> > >>>> I really do not want to make any changes to this - ignoring the include > >>>> macro changes everything we have is working perfectly fine just the > way > >>>> the defines are. So I don't want to see this change potentially break > >>>> that through incidental changes. > >>>> > >>>> I do not see having the following is a big issue: > >>>> > >>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>> > >>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and > >>>> TARGET_ARCH_arm to mean whatever the owners of that define > intend > >> it to > >>>> mean. It certainly is a lot better than interpreting what the > >>>> combinations of AARCH64 and ARM mean. Keeping this removes the > >> need to > >>>> perform some of the changes as noted above. > >>>> > >>>> I'm preparing the review of the internal changes we need to > accompany > >> this. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> These should not break the open port if ARM gets defined, or can be > >> fixed > >>>> easily. > >>>>> --------------------------------------------------------- > >>>>> > >>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>> print[1519] #elif defined(ARM) > >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>> > >>>>> *** os/linux/vm/os_linux.cpp: > >>>>> dll_load[1796] #elif (defined ARM) > >>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>> > >>>>> *** share/vm/opto/matcher.cpp: > >>>>> init_first_stack_mask[558] #ifdef ARM > >>>>> ==> Should be ARM32 (Is under !LP64). > >>>>> > >>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > >>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > >>>>> ==> Just an assertion. Will just relax the check if defined in open > >> AARCH64. > >>>>> But maybe should be guarded by __SOFTFP__. > >>>>> [70] #if defined(ARM) || defined(AARCH64) || > >>>> defined(PPC64) > >>>>> ==> Fine: || > >>>>> > >>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>> [447] #if defined(SPARC) || defined(ARM) || > >>>> defined(PPC) || defined(AARCH64) > >>>>> [537] #if defined(X86) || defined(ARM) || > >>>> defined(AARCH64) > >>>>> ==> Fine: || > >>>>> > >>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>> defined[162] #if defined(IA32) || defined(AMD64) || > >>>> defined(ARM) > >>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>> [1358] #if defined(IA32) || defined(AMD64) || > >>>> defined(ARM) > >>>>> ==> Just defines a method which would be unused, should be fine. > >>>>> > >>>>> > >>>>> These are in code not used in the open AARCH64 port: > >>>>> -------------------------------------------------- > >>>>> > >>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>> [215] #elif defined(ARM) > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>> [102] #ifdef ARM > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>> [31] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>> [102] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>> [31] #ifdef ARM > >>>>> > >>>>> *** share/vm/utilities/macros.hpp: > >>>>> [434] #ifdef ARM > >>>>> > >>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>> dll_load[1508] #elif (defined ARM) > >>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, > ARM, > >>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>> > >>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>> dll_load[1725] #elif (defined ARM) > >>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, > ARM, > >>>> ARM > >>>>> > >>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>> store[164] #if !defined(ARM) && !defined(M68K) > >>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) > >>>>> add[178] #ifdef ARM > >>>>> add_ptr[190] #ifdef ARM > >>>>> xchg[230] #ifdef ARM > >>>>> xchg_ptr[253] #ifdef ARM > >>>>> cmpxchg[275] #ifdef ARM > >>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>> > >>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>> add[172] #ifdef ARM > >>>>> add_ptr[184] #ifdef ARM > >>>>> xchg[224] #ifdef ARM > >>>>> xchg_ptr[247] #ifdef ARM > >>>>> cmpxchg[269] #ifdef ARM > >>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. > >>>>>>> (Parisc is gone, puh!). > >>>>>>> We basically patch all the shared changes onto the sources after > >>>>>>> getting them via our licensee channel. > >>>>>>> I think you should fix your closed port not to re-use the names of > the > >>>>>>> main openJdk platforms! > >>>>>> > >>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to > have > >> to > >>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" > so > >>>>>> we worked with the Open port to ensure that shared code guarded > by > >>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >> identify > >>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >> places > >>>>>> that needed it. And sometimes we have to be careful and ensure > that > >>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>> > >>>>>> This has all been working quite nicely, as the include guards used, for > >>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which > >> are > >>>>>> never > >>>>>> defined at the same time (derived from > >> HOTSPOT_TARGET_CPU_ARCH). > >>>> But > >>>>>> the > >>>>>> current changes remove those unique defines and, before the > >> HEADER_H > >>>>>> forms were introduced, tried to use simple AARCH64 and ARM as > >> include > >>>>>> guards, and that doesn't work as they are not mutually exclusive. > >>>>>> > >>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>> keeping them so they can be used as include guards (or other > >> conditional > >>>>>> code) when needed, and where the macros are not suitable. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> I have no idea what hardware is addressed by your closed ports, > >>>>>>> nor how you merge sources. > >>>>>>> Is there also a port that sets > >>>>>>> -DTARGET_ARCH_arm > >>>>>>> -DARM > >>>>>>> -DARM32 > >>>>>>> ? > >>>>>>> > >>>>>>> To fix this either you define > >>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>> #define ARM64 > >>>>>>> #endif > >>>>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>>>> Then you replace all > >>>>>>> #ifdef AARCH64 > >>>>>>> by > >>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>> or maybe it suffices altogether f you replace > >>>>>>> #ifdef AARCH64 > >>>>>>> by > >>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>> > >>>>>>> For ppc, when we did the port we knew (and that's all we knew) > >>>>>>> that you have a 32-bit port. Therefore we set up these macros > >>>>>>> as on x86, where there is one for the arch (X86) and two for > >> LP64/!LP64 > >>>>>>> (IA32, AMD64). This allowed to separate code for the closed port > >>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both > >> (PPC). > >>>>>>> > >>>>>>> But I don't think it is necessary to do any further changes now, > >> assuming > >>>>>>> my change works for you as I adapted it. So we're all set I guess! > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > kind > >> of > >>>>>>>>>> workaround is obscure - you have to know that the Open > Aarch64 > >>>> port > >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > >> port > >>>>>> use > >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>> something > >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>> > >>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>> And I'm uneasy that it is no more. How do you handle that? You > >> have > >>>> to > >>>>>>>>> check every AARCH change by RedHat against your closed port? > >>>>>>>> > >>>>>>>> The sources for the two ports are distinct so the only place we > have > >> to > >>>>>>>> have a convention is in shared code that has CPU specific stuff and > in > >>>>>>>> the build files. > >>>>>>>> > >>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>> -DAARCH64 > >>>>>>>> > >>>>>>>> the closed port sets > >>>>>>>> > >>>>>>>> -DTARGET_ARCH_arm > >>>>>>>> -DARM > >>>>>>>> -DAARCH64 > >>>>>>>> > >>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. > >>>>>> Whenever > >>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was > referring > >> to > >>>>>> our > >>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open > Aarch64 > >>>> port. > >>>>>>>> > >>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >>>>>>>> > >>>>>>>> We need to keep a clear distinction. Using the combination of > >> AARCH64 > >>>>>>>> and ARM is not so clear. > >>>>>>>> > >>>>>>>> You could easily have similar issues with other port groups - eg > ppc64 > >>>>>>>> vs ppc32 vs ppcle. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>>>> I don't know about the closed stuff, but aarch came up recently, > >> and > >>>>>>>>> before that it sure was equivalent. And it still is the case for > >> openJDK. > >>>>>>>>> > >>>>>>>>> Below output is grepped out of the make//platform_ > >> files > >>>> in > >>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined > twice. > >>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > D_GNU_SOURCE > >> - > >>>>>>>> DAMD64 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > D_GNU_SOURCE > >> - > >>>>>> DIA32 > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - > >> DCC_INTERP > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - > >>>> DZERO - > >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > DAMD64 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any further > >>>> issues, > >>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>> > >>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>> and fixed the other issues mentioned by David and Coleen in > this > >>>> new > >>>>>>>>>> webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>> > >>>>>>>>>>> I also added comments that AARCH64 and ARM are defined > >>>>>>>>>>> at the same time. > >>>>>>>>>>> > >>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>> > >>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > kind > >> of > >>>>>>>>>> workaround is obscure - you have to know that the Open > Aarch64 > >>>> port > >>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open > >> port > >>>>>> use > >>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>> something > >>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >>>> Barrett > >>>>>>>>>>>> > >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be > >> fixed > >>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) > >>>>>>>>>>>>> > >>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value > for > >> the > >>>>>> ifdef > >>>>>>>> is > >>>>>>>>>> not > >>>>>>>>>>>>> going to work for our closed ports, unless I change that > value > >> to > >>>>>>>> match > >>>>>>>>>>>>> the open naming scheme. But that in turn will lead to other > >>>>>> problems > >>>>>>>> as > >>>>>>>>>>>>> we also need that value the way it is currently defined. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>>>>>> > >>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. > In > >>>>>> general > >>>>>>>> you > >>>>>>>>>>>> can't just replace: > >>>>>>>>>>>> > >>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>> > >>>>>>>>>>>> with > >>>>>>>>>>>> > >>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>> > >>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our > case > >>>> ARM > >>>>>>>> and > >>>>>>>>>>>> AARCH64 are both defined and are both needed. In contrast > >>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to > >>>>>> represent > >>>>>>>> the > >>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > >> Kim > >>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >>>> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > >> .hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> can we not define a second form, eg > CPU_HEADER_H, > >>>> that > >>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > used > >>>> only > >>>>>>>> once. > >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it > to > >> get > >>>> is > >>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need > not > >>>> be > >>>>>>>>>> mutually > >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs > to > >> be > >>>> an > >>>>>> if- > >>>>>>>>>> else > >>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in > >>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the > >> closed > >>>>>> part > >>>>>>>> of > >>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we > get > >>>> both > >>>>>>>>>> defined > >>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to > >> understand > >>>>>> what > >>>>>>>>>> the > >>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to > be, > >> as > >>>> we > >>>>>>>> are > >>>>>>>>>> not > >>>>>>>>>>>>>>> overriding it for our port - which I think is the current > >> problem, > >>>>>> but > >>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>>> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; > >>>>>> Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and > >>>>>> comments > >>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch > directory, > >> but > >>>> I > >>>>>>>> don't > >>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. > >> (Sorry I > >>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs > to > >>>> be > >>>>>>>>>> changed > >>>>>>>>>>>> on > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) > >>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that > has > >>>> the > >>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 > >> header > >>>>>> files if > >>>>>>>> I > >>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches > >>>> internally > >>>>>> for > >>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not > hold: > >>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was a > >>>> common > >>>>>> file > >>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid > this > >>>> kind > >>>>>> of > >>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in > TARGET_SO... > >>>>>>>>>>>>>>>>>> Actually I think the implementation should be moved > to > >>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be > >> elided > >>>>>> here ?? > >>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the > >>>>>> umbrella > >>>>>>>>>> header > >>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends > >> .hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> can we not define a second form, eg > CPU_HEADER_H, > >>>> that > >>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > used > >>>> only > >>>>>>>> once. > >>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it > to > >> get > >>>> is > >>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> We actually need this as the simple arch names need > not > >>>> be > >>>>>>>>>> mutually > >>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs > to > >> be > >>>> an > >>>>>> if- > >>>>>>>>>> else > >>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is > >> that > >>>>>>>> coming > >>>>>>>>>>>> from > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined > >>>> WINDOWS > >>>>>> in > >>>>>>>> the > >>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is > defining > >> - > >>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, > but > >> not > >>>> in > >>>>>> this > >>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the > >> unused > >>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>> I wanted to document why there is this empty file. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>> ; > >>>>>> Kim > >>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>> hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>> platform > >>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's > working > >> on > >>>> all > >>>>>> the > >>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the > >> macros > >>>> and > >>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name > >>>>>> construction > >>>>>>>> are > >>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in > macros.hpp. > >> But > >>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses > >> the > >>>>>> very > >>>>>>>>>> same > >>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could > include > >>>> that > >>>>>> in > >>>>>>>> the > >>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as > fine > >>>> with > >>>>>> your > >>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that > >> the > >>>>>> linux=1 > >>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should > be > >>>>>> upper > >>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; > hotspot- > >>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>> platform > >>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, > Goetz > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> please take into account that these macros > are > >>>> only > >>>>>>>> used > >>>>>>>>>>>> within > >>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody > needs > >> to > >>>>>>>>>> understand > >>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp > and > >>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to > >> spend > >>>> days > >>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my > >>>> current > >>>>>>>>>> progress > >>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do > is > >>>> adding > >>>>>> the > >>>>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>>>> > >> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. > >>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker > >>>> proposed > >>>>>> in > >>>>>>>> that > >>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>> > >> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email > thread > >> for > >>>>>> me; it > >>>>>>>>>> looks > >>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler- > dev > >> but > >>>>>> not > >>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list > this > >>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've > >> only > >>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can > wait > >>>> until > >>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> ---- > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing > >>>> #defines > >>>>>>>> that > >>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: > >>>> linux=1, > >>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the > leading > >>>>>>>> underscore > >>>>>>>>>>>> part > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>>>> > >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the > values. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>> > >> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets > >> instead > >>>> of > >>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are > >>>> defined, > >>>>>> but > >>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that > >>>> underscore > >>>>>>>>>>>> followed > >>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word > >> pattern > >>>>>> for > >>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use > uppercase > >> for > >>>>>> the > >>>>>>>>>> macro > >>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- > --- > >> ---- > >>>> --- > >>>>>> ---- > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> From david.holmes at oracle.com Thu Jul 21 10:00:25 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2016 20:00:25 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> Message-ID: On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: > Hi David, > > Copyright of register_definitions_x86.cpp is already fixed in hs-comp, > I'll skip it to avoid merges. This isn't going into hs-comp so I don't know when the two will collide. I would deal with it anyway - I can just apply the patch without committing, deal with any merges, and then commit as you. > I fixed the others. New webrevs, also with Coleens fixes: > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ I see the typo was actually much bigger than I thought :) Presumably the INLCUDE typo caused it to be missed by a global search replace. > I also did another zero build configured as follows: > --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm-variants=zero > on linuxx86_64. Thanks. David > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 21. Juli 2016 05:26 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>> Hi >>> >>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >> newPfmIncl/webrev.04/ >>> >>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >> CompileJvm.gmk >>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I >> documented >>> what I learned about the platform defines in macros.hpp. >> >> Thanks - much appreciated. Other than Coleen's typo (well spotted!) and >> the lingering _32 the only nit I have left is a handful of copyright >> updates: >> >> src/cpu/x86/vm/register_definitions_x86.cpp: >> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >> src/share/vm/runtime/semaphore.hpp: >> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >> src/cpu/ppc/vm/templateTable_ppc.hpp >> >> Then all we need is confirmation that all the open platforms that Oracle >> doesn't also build (aarch64 and Zero) build and run successfully after >> this change. >> >> I will sponsor this (in case that wasn't clear) but may have to delay it >> until after we sync up the hs forest with the CPU changes now in >> jdk9/dev. I will rebase and handle any merging if needed. >> >> Thanks, >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> OK, to get this through I will add >>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>> and revert this one and only place it needs to be used in the >>>> vmStructs_jvmci.cpp. >>>> >>>> Thanks. >>>> >>>>> For the records, openJdk aarch64 has a C1 port. And yes, such cleanups >>>> should >>>>> not be in this change. >>>> >>>> I did not know they had a 64-bit C1 - interesting. >>>> >>>>> >>>>> Thanks for doing the closed changes! >>>> >>>> You're welcome. >>>> >>>> Cheers, >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> that's great what you are saying and just the design I would expect! >>>>>>>> We did not want to have to >>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" >> so >>>>>>>> we worked with the Open port to ensure that shared code guarded >> by >>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>> identify >>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>> places >>>>>>>> that needed it. And sometimes we have to be careful and ensure >> that >>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>> >>>>>>> I think as a consequence the open AARCH port should define ARM, >> too. >>>>>> >>>>>> I would not want to do this and certainly not as part of this change. >>>>>> If/when the Aarch32 port arrives we may have to revisit this, but not >>>>>> right now, please. >>>>>> >>>>>>> I checked the occurrences and only see three places where this would >>>> have >>>>>>> an effect and would have to be fixed somehow: >>>>>>> >>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>> [610] #if defined(AARCH64) && !defined(ARM) >>>>>>> ==> Would this break the closed port if defined? >>>>>> >>>>>> Yes - it refers to specific piece of code in the open aarch64 sources. >>>>>> >>>>>>> (This is the only place where TARGET_ARCH_aarch64 was used) >>>>>>> >>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) >>>>>>> ==> Would this break the open port if defined? >>>>>>> >>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>> [1154] #ifdef ARM >>>>>>> ==> Would this break the open port if defined? >>>>>> >>>>>> I don't think the open port has C1 so it would ignore the above files >>>>>> anyway. >>>>>> >>>>>>> All the cases below are pointless. >>>>>>> >>>>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>>>> keeping them so they can be used as include guards (or other >>>> conditional >>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>> I think it's quite misleading to have two defines that are 99% >> equivalent. >>>>>>> If we really need a special case here, you should define - >> DARM_CLOSED >>>>>>> or the like in your closed port. Such a name would make clear what's >> the >>>>>>> issue. At least, only your closed port has this problem. >>>>>> >>>>>> I really do not want to make any changes to this - ignoring the include >>>>>> macro changes everything we have is working perfectly fine just the >> way >>>>>> the defines are. So I don't want to see this change potentially break >>>>>> that through incidental changes. >>>>>> >>>>>> I do not see having the following is a big issue: >>>>>> >>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>> >>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>>>> TARGET_ARCH_arm to mean whatever the owners of that define >> intend >>>> it to >>>>>> mean. It certainly is a lot better than interpreting what the >>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the >>>> need to >>>>>> perform some of the changes as noted above. >>>>>> >>>>>> I'm preparing the review of the internal changes we need to >> accompany >>>> this. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> These should not break the open port if ARM gets defined, or can be >>>> fixed >>>>>> easily. >>>>>>> --------------------------------------------------------- >>>>>>> >>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>> print[1519] #elif defined(ARM) >>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>> >>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>> >>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>> >>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) >>>>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) >>>>>>> ==> Just an assertion. Will just relax the check if defined in open >>>> AARCH64. >>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>> [70] #if defined(ARM) || defined(AARCH64) || >>>>>> defined(PPC64) >>>>>>> ==> Fine: || >>>>>>> >>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>> [447] #if defined(SPARC) || defined(ARM) || >>>>>> defined(PPC) || defined(AARCH64) >>>>>>> [537] #if defined(X86) || defined(ARM) || >>>>>> defined(AARCH64) >>>>>>> ==> Fine: || >>>>>>> >>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>> defined[162] #if defined(IA32) || defined(AMD64) || >>>>>> defined(ARM) >>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>> [1358] #if defined(IA32) || defined(AMD64) || >>>>>> defined(ARM) >>>>>>> ==> Just defines a method which would be unused, should be fine. >>>>>>> >>>>>>> >>>>>>> These are in code not used in the open AARCH64 port: >>>>>>> -------------------------------------------------- >>>>>>> >>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>> [215] #elif defined(ARM) >>>>>>> >>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>> [102] #ifdef ARM >>>>>>> >>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>> [31] #ifdef ARM >>>>>>> >>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>> [102] #ifdef ARM >>>>>>> >>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>> [31] #ifdef ARM >>>>>>> >>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>> [434] #ifdef ARM >>>>>>> >>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, >> ARM, >>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>> >>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, >> ARM, >>>>>> ARM >>>>>>> >>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>> store[164] #if !defined(ARM) && !defined(M68K) >>>>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) >>>>>>> add[178] #ifdef ARM >>>>>>> add_ptr[190] #ifdef ARM >>>>>>> xchg[230] #ifdef ARM >>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>> cmpxchg[275] #ifdef ARM >>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>> >>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>> add[172] #ifdef ARM >>>>>>> add_ptr[184] #ifdef ARM >>>>>>> xchg[224] #ifdef ARM >>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>> cmpxchg[269] #ifdef ARM >>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>>>> (Parisc is gone, puh!). >>>>>>>>> We basically patch all the shared changes onto the sources after >>>>>>>>> getting them via our licensee channel. >>>>>>>>> I think you should fix your closed port not to re-use the names of >> the >>>>>>>>> main openJdk platforms! >>>>>>>> >>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to >> have >>>> to >>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit ARM" >> so >>>>>>>> we worked with the Open port to ensure that shared code guarded >> by >>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>> identify >>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>> places >>>>>>>> that needed it. And sometimes we have to be careful and ensure >> that >>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>> >>>>>>>> This has all been working quite nicely, as the include guards used, for >>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - which >>>> are >>>>>>>> never >>>>>>>> defined at the same time (derived from >>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>> But >>>>>>>> the >>>>>>>> current changes remove those unique defines and, before the >>>> HEADER_H >>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >>>> include >>>>>>>> guards, and that doesn't work as they are not mutually exclusive. >>>>>>>> >>>>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>>>> keeping them so they can be used as include guards (or other >>>> conditional >>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> I have no idea what hardware is addressed by your closed ports, >>>>>>>>> nor how you merge sources. >>>>>>>>> Is there also a port that sets >>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>> -DARM >>>>>>>>> -DARM32 >>>>>>>>> ? >>>>>>>>> >>>>>>>>> To fix this either you define >>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>> #define ARM64 >>>>>>>>> #endif >>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>> Then you replace all >>>>>>>>> #ifdef AARCH64 >>>>>>>>> by >>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>> #ifdef AARCH64 >>>>>>>>> by >>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>> >>>>>>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>>>>>> that you have a 32-bit port. Therefore we set up these macros >>>>>>>>> as on x86, where there is one for the arch (X86) and two for >>>> LP64/!LP64 >>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed port >>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both >>>> (PPC). >>>>>>>>> >>>>>>>>> But I don't think it is necessary to do any further changes now, >>>> assuming >>>>>>>>> my change works for you as I adapted it. So we're all set I guess! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >> kind >>>> of >>>>>>>>>>>> workaround is obscure - you have to know that the Open >> Aarch64 >>>>>> port >>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open >>>> port >>>>>>>> use >>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>>>> something >>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>> >>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? You >>>> have >>>>>> to >>>>>>>>>>> check every AARCH change by RedHat against your closed port? >>>>>>>>>> >>>>>>>>>> The sources for the two ports are distinct so the only place we >> have >>>> to >>>>>>>>>> have a convention is in shared code that has CPU specific stuff and >> in >>>>>>>>>> the build files. >>>>>>>>>> >>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>> -DAARCH64 >>>>>>>>>> >>>>>>>>>> the closed port sets >>>>>>>>>> >>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>> -DARM >>>>>>>>>> -DAARCH64 >>>>>>>>>> >>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >>>>>>>> Whenever >>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was >> referring >>>> to >>>>>>>> our >>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open >> Aarch64 >>>>>> port. >>>>>>>>>> >>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>>>> >>>>>>>>>> We need to keep a clear distinction. Using the combination of >>>> AARCH64 >>>>>>>>>> and ARM is not so clear. >>>>>>>>>> >>>>>>>>>> You could easily have similar issues with other port groups - eg >> ppc64 >>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I don't know about the closed stuff, but aarch came up recently, >>>> and >>>>>>>>>>> before that it sure was equivalent. And it still is the case for >>>> openJDK. >>>>>>>>>>> >>>>>>>>>>> Below output is grepped out of the make//platform_ >>>> files >>>>>> in >>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined >> twice. >>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >> D_GNU_SOURCE >>>> - >>>>>>>>>> DAMD64 >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >> D_GNU_SOURCE >>>> - >>>>>>>> DIA32 >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >>>> DCC_INTERP >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP - >>>>>> DZERO - >>>>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >> DAMD64 >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -DIA32 >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>>>> D at ZERO_ARCHDEF@ -DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>> >>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any further >>>>>> issues, >>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>> >>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen in >> this >>>>>> new >>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>> >>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>>>> at the same time. >>>>>>>>>>>>> >>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>> >>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >> kind >>>> of >>>>>>>>>>>> workaround is obscure - you have to know that the Open >> Aarch64 >>>>>> port >>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the Open >>>> port >>>>>>>> use >>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>>>> something >>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>> Barrett >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should be >>>> fixed >>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value >> for >>>> the >>>>>>>> ifdef >>>>>>>>>> is >>>>>>>>>>>> not >>>>>>>>>>>>>>> going to work for our closed ports, unless I change that >> value >>>> to >>>>>>>>>> match >>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to other >>>>>>>> problems >>>>>>>>>> as >>>>>>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H macro. >> In >>>>>>>> general >>>>>>>>>> you >>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>> >>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>> >>>>>>>>>>>>>> with >>>>>>>>>>>>>> >>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>> >>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our >> case >>>>>> ARM >>>>>>>>>> and >>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In contrast >>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen to >>>>>>>> represent >>>>>>>>>> the >>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends >>>> .hpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >> CPU_HEADER_H, >>>>>> that >>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >> used >>>>>> only >>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it >> to >>>> get >>>>>> is >>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names need >> not >>>>>> be >>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs >> to >>>> be >>>>>> an >>>>>>>> if- >>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>> in the same statement as the INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from the >>>> closed >>>>>>>> part >>>>>>>>>> of >>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So we >> get >>>>>> both >>>>>>>>>>>> defined >>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >>>> understand >>>>>>>> what >>>>>>>>>>>> the >>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to >> be, >>>> as >>>>>> we >>>>>>>>>> are >>>>>>>>>>>> not >>>>>>>>>>>>>>>>> overriding it for our port - which I think is the current >>>> problem, >>>>>>>> but >>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; >>>>>> Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>> ; >>>>>>>> Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>> hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz >> wrote: >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications and >>>>>>>> comments >>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch >> directory, >>>> but >>>>>> I >>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. >>>> (Sorry I >>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what needs >> to >>>>>> be >>>>>>>>>>>> changed >>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this :).) >>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory that >> has >>>>>> the >>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >>>> header >>>>>>>> files if >>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches >>>>>> internally >>>>>>>> for >>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not >> hold: >>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was a >>>>>> common >>>>>>>> file >>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to avoid >> this >>>>>> kind >>>>>>>> of >>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >> TARGET_SO... >>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be moved >> to >>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >>>> elided >>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is the >>>>>>>> umbrella >>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it appends >>>> .hpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >> CPU_HEADER_H, >>>>>> that >>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >> used >>>>>> only >>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do it >> to >>>> get >>>>>> is >>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names need >> not >>>>>> be >>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this needs >> to >>>> be >>>>>> an >>>>>>>> if- >>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of WINDOWS? Is >>>> that >>>>>>>>>> coming >>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>>>> WINDOWS >>>>>>>> in >>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is >> defining >>>> - >>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, >> but >>>> not >>>>>> in >>>>>>>> this >>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >>>> unused >>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty file. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>> ; >>>>>>>> Kim >>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>> hotspot- >>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>> platform >>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz >> wrote: >>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's >> working >>>> on >>>>>> all >>>>>>>> the >>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the >>>> macros >>>>>> and >>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>>>> construction >>>>>>>>>> are >>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >> macros.hpp. >>>> But >>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and uses >>>> the >>>>>>>> very >>>>>>>>>>>> same >>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could >> include >>>>>> that >>>>>>>> in >>>>>>>>>> the >>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as >> fine >>>>>> with >>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is that >>>> the >>>>>>>> linux=1 >>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros should >> be >>>>>>>> upper >>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; >> hotspot- >>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>> platform >>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, >> Goetz >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these macros >> are >>>>>> only >>>>>>>>>> used >>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody >> needs >>>> to >>>>>>>>>>>> understand >>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp >> and >>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to >>>> spend >>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted my >>>>>> current >>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to do >> is >>>>>> adding >>>>>>>> the >>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the includes. >>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>>>> proposed >>>>>>>> in >>>>>>>>>> that >>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email >> thread >>>> for >>>>>>>> me; it >>>>>>>>>>>> looks >>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot-compiler- >> dev >>>> but >>>>>>>> not >>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list >> this >>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. I've >>>> only >>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can >> wait >>>>>> until >>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- >> --- >>>> ---- >>>>>> --- >>>>>>>> ---- >>>>>>>>>> --- >>>>>>>>>>>> --- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround existing >>>>>> #defines >>>>>>>>>> that >>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so far: >>>>>> linux=1, >>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the >> leading >>>>>>>>>> underscore >>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>> >>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the >> values. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written as >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>> >> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>> >> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>> >>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >>>> instead >>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) are >>>>>> defined, >>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>>>> underscore >>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >>>> pattern >>>>>>>> for >>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use >> uppercase >>>> for >>>>>>>> the >>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------- >> --- >>>> ---- >>>>>> --- >>>>>>>> ---- >>>>>>>>>> --- >>>>>>>>>>>> --- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From goetz.lindenmaier at sap.com Thu Jul 21 10:59:20 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Jul 2016 10:59:20 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> Message-ID: <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> Hi, > I see the typo was actually much bigger than I thought :) Presumably the Well, I edited it some more ... this time I replaced the webrev in-place, webrev.05 is fixed now. I really should have an aarch64 machine :) Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 21. Juli 2016 12:00 > To: Lindenmaier, Goetz ; Kim Barrett > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > Copyright of register_definitions_x86.cpp is already fixed in hs-comp, > > I'll skip it to avoid merges. > > This isn't going into hs-comp so I don't know when the two will collide. > I would deal with it anyway - I can just apply the patch without > committing, deal with any merges, and then commit as you. > > > I fixed the others. New webrevs, also with Coleens fixes: > > http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ > > I see the typo was actually much bigger than I thought :) Presumably the > INLCUDE typo caused it to be missed by a global search replace. > > > I also did another zero build configured as follows: > > --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- > variants=zero > > on linuxx86_64. > > Thanks. > > David > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Donnerstag, 21. Juli 2016 05:26 > >> To: Lindenmaier, Goetz ; Kim Barrett > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > >>> Hi > >>> > >>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- > >> newPfmIncl/webrev.04/ > >>> > >>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > >> CompileJvm.gmk > >>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I > >> documented > >>> what I learned about the platform defines in macros.hpp. > >> > >> Thanks - much appreciated. Other than Coleen's typo (well spotted!) and > >> the lingering _32 the only nit I have left is a handful of copyright > >> updates: > >> > >> src/cpu/x86/vm/register_definitions_x86.cpp: > >> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > >> src/share/vm/runtime/semaphore.hpp: > >> src/cpu/ppc/vm/stubRoutines_ppc.hpp: > >> src/cpu/ppc/vm/templateTable_ppc.hpp > >> > >> Then all we need is confirmation that all the open platforms that Oracle > >> doesn't also build (aarch64 and Zero) build and run successfully after > >> this change. > >> > >> I will sponsor this (in case that wasn't clear) but may have to delay it > >> until after we sync up the hs forest with the CPU changes now in > >> jdk9/dev. I will rebase and handle any merging if needed. > >> > >> Thanks, > >> David > >> ----- > >> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 20. Juli 2016 12:05 > >>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>> > >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>> > >>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> OK, to get this through I will add > >>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>> and revert this one and only place it needs to be used in the > >>>> vmStructs_jvmci.cpp. > >>>> > >>>> Thanks. > >>>> > >>>>> For the records, openJdk aarch64 has a C1 port. And yes, such > cleanups > >>>> should > >>>>> not be in this change. > >>>> > >>>> I did not know they had a 64-bit C1 - interesting. > >>>> > >>>>> > >>>>> Thanks for doing the closed changes! > >>>> > >>>> You're welcome. > >>>> > >>>> Cheers, > >>>> David > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> that's great what you are saying and just the design I would expect! > >>>>>>>> We did not want to have to > >>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit > ARM" > >> so > >>>>>>>> we worked with the Open port to ensure that shared code > guarded > >> by > >>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >>>> identify > >>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >>>> places > >>>>>>>> that needed it. And sometimes we have to be careful and ensure > >> that > >>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>> > >>>>>>> I think as a consequence the open AARCH port should define ARM, > >> too. > >>>>>> > >>>>>> I would not want to do this and certainly not as part of this change. > >>>>>> If/when the Aarch32 port arrives we may have to revisit this, but not > >>>>>> right now, please. > >>>>>> > >>>>>>> I checked the occurrences and only see three places where this > would > >>>> have > >>>>>>> an effect and would have to be fixed somehow: > >>>>>>> > >>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>>>> [610] #if defined(AARCH64) && !defined(ARM) > >>>>>>> ==> Would this break the closed port if defined? > >>>>>> > >>>>>> Yes - it refers to specific piece of code in the open aarch64 sources. > >>>>>> > >>>>>>> (This is the only place where TARGET_ARCH_aarch64 was > used) > >>>>>>> > >>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) > >>>>>>> ==> Would this break the open port if defined? > >>>>>>> > >>>>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>>>> [1154] #ifdef ARM > >>>>>>> ==> Would this break the open port if defined? > >>>>>> > >>>>>> I don't think the open port has C1 so it would ignore the above files > >>>>>> anyway. > >>>>>> > >>>>>>> All the cases below are pointless. > >>>>>>> > >>>>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>>>> keeping them so they can be used as include guards (or other > >>>> conditional > >>>>>>>> code) when needed, and where the macros are not suitable. > >>>>>>> I think it's quite misleading to have two defines that are 99% > >> equivalent. > >>>>>>> If we really need a special case here, you should define - > >> DARM_CLOSED > >>>>>>> or the like in your closed port. Such a name would make clear > what's > >> the > >>>>>>> issue. At least, only your closed port has this problem. > >>>>>> > >>>>>> I really do not want to make any changes to this - ignoring the > include > >>>>>> macro changes everything we have is working perfectly fine just the > >> way > >>>>>> the defines are. So I don't want to see this change potentially break > >>>>>> that through incidental changes. > >>>>>> > >>>>>> I do not see having the following is a big issue: > >>>>>> > >>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>> > >>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and > >>>>>> TARGET_ARCH_arm to mean whatever the owners of that define > >> intend > >>>> it to > >>>>>> mean. It certainly is a lot better than interpreting what the > >>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the > >>>> need to > >>>>>> perform some of the changes as noted above. > >>>>>> > >>>>>> I'm preparing the review of the internal changes we need to > >> accompany > >>>> this. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> These should not break the open port if ARM gets defined, or can > be > >>>> fixed > >>>>>> easily. > >>>>>>> --------------------------------------------------------- > >>>>>>> > >>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>> print[1519] #elif defined(ARM) > >>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>> > >>>>>>> *** os/linux/vm/os_linux.cpp: > >>>>>>> dll_load[1796] #elif (defined ARM) > >>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>> > >>>>>>> *** share/vm/opto/matcher.cpp: > >>>>>>> init_first_stack_mask[558] #ifdef ARM > >>>>>>> ==> Should be ARM32 (Is under !LP64). > >>>>>>> > >>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) > >>>>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) > >>>>>>> ==> Just an assertion. Will just relax the check if defined in open > >>>> AARCH64. > >>>>>>> But maybe should be guarded by __SOFTFP__. > >>>>>>> [70] #if defined(ARM) || defined(AARCH64) || > >>>>>> defined(PPC64) > >>>>>>> ==> Fine: || > >>>>>>> > >>>>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>>>> [447] #if defined(SPARC) || defined(ARM) || > >>>>>> defined(PPC) || defined(AARCH64) > >>>>>>> [537] #if defined(X86) || defined(ARM) || > >>>>>> defined(AARCH64) > >>>>>>> ==> Fine: || > >>>>>>> > >>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>>>> defined[162] #if defined(IA32) || defined(AMD64) || > >>>>>> defined(ARM) > >>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>>>> [1358] #if defined(IA32) || defined(AMD64) || > >>>>>> defined(ARM) > >>>>>>> ==> Just defines a method which would be unused, should be fine. > >>>>>>> > >>>>>>> > >>>>>>> These are in code not used in the open AARCH64 port: > >>>>>>> -------------------------------------------------- > >>>>>>> > >>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>> [215] #elif defined(ARM) > >>>>>>> > >>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>> [102] #ifdef ARM > >>>>>>> > >>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>>>> [31] #ifdef ARM > >>>>>>> > >>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>> [102] #ifdef ARM > >>>>>>> > >>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>>>> [31] #ifdef ARM > >>>>>>> > >>>>>>> *** share/vm/utilities/macros.hpp: > >>>>>>> [434] #ifdef ARM > >>>>>>> > >>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>> dll_load[1508] #elif (defined ARM) > >>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, > >> ARM, > >>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>>>> > >>>>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>>>> dll_load[1725] #elif (defined ARM) > >>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, > >> ARM, > >>>>>> ARM > >>>>>>> > >>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>> store[164] #if !defined(ARM) && !defined(M68K) > >>>>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) > >>>>>>> add[178] #ifdef ARM > >>>>>>> add_ptr[190] #ifdef ARM > >>>>>>> xchg[230] #ifdef ARM > >>>>>>> xchg_ptr[253] #ifdef ARM > >>>>>>> cmpxchg[275] #ifdef ARM > >>>>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>>>> > >>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>> add[172] #ifdef ARM > >>>>>>> add_ptr[184] #ifdef ARM > >>>>>>> xchg[224] #ifdef ARM > >>>>>>> xchg_ptr[247] #ifdef ARM > >>>>>>> cmpxchg[269] #ifdef ARM > >>>>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> Hi Goetz, > >>>>>>>> > >>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. > >>>>>>>>> (Parisc is gone, puh!). > >>>>>>>>> We basically patch all the shared changes onto the sources after > >>>>>>>>> getting them via our licensee channel. > >>>>>>>>> I think you should fix your closed port not to re-use the names of > >> the > >>>>>>>>> main openJdk platforms! > >>>>>>>> > >>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to > >> have > >>>> to > >>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit > ARM" > >> so > >>>>>>>> we worked with the Open port to ensure that shared code > guarded > >> by > >>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to > >>>> identify > >>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of > >>>> places > >>>>>>>> that needed it. And sometimes we have to be careful and ensure > >> that > >>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>> > >>>>>>>> This has all been working quite nicely, as the include guards used, > for > >>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - > which > >>>> are > >>>>>>>> never > >>>>>>>> defined at the same time (derived from > >>>> HOTSPOT_TARGET_CPU_ARCH). > >>>>>> But > >>>>>>>> the > >>>>>>>> current changes remove those unique defines and, before the > >>>> HEADER_H > >>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as > >>>> include > >>>>>>>> guards, and that doesn't work as they are not mutually exclusive. > >>>>>>>> > >>>>>>>> So what I'm suggesting is just not getting rid of those defines, but > >>>>>>>> keeping them so they can be used as include guards (or other > >>>> conditional > >>>>>>>> code) when needed, and where the macros are not suitable. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>>> I have no idea what hardware is addressed by your closed ports, > >>>>>>>>> nor how you merge sources. > >>>>>>>>> Is there also a port that sets > >>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>> -DARM > >>>>>>>>> -DARM32 > >>>>>>>>> ? > >>>>>>>>> > >>>>>>>>> To fix this either you define > >>>>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>>>> #define ARM64 > >>>>>>>>> #endif > >>>>>>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>>>>>> Then you replace all > >>>>>>>>> #ifdef AARCH64 > >>>>>>>>> by > >>>>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>>>> or maybe it suffices altogether f you replace > >>>>>>>>> #ifdef AARCH64 > >>>>>>>>> by > >>>>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>>>> > >>>>>>>>> For ppc, when we did the port we knew (and that's all we knew) > >>>>>>>>> that you have a 32-bit port. Therefore we set up these macros > >>>>>>>>> as on x86, where there is one for the arch (X86) and two for > >>>> LP64/!LP64 > >>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed port > >>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both > >>>> (PPC). > >>>>>>>>> > >>>>>>>>> But I don't think it is necessary to do any further changes now, > >>>> assuming > >>>>>>>>> my change works for you as I adapted it. So we're all set I guess! > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi David, > >>>>>>>>>>> > >>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > >> kind > >>>> of > >>>>>>>>>>>> workaround is obscure - you have to know that the Open > >> Aarch64 > >>>>>> port > >>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the > Open > >>>> port > >>>>>>>> use > >>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>>>> something > >>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>>>> > >>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? > You > >>>> have > >>>>>> to > >>>>>>>>>>> check every AARCH change by RedHat against your closed > port? > >>>>>>>>>> > >>>>>>>>>> The sources for the two ports are distinct so the only place we > >> have > >>>> to > >>>>>>>>>> have a convention is in shared code that has CPU specific stuff > and > >> in > >>>>>>>>>> the build files. > >>>>>>>>>> > >>>>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>>>> -DAARCH64 > >>>>>>>>>> > >>>>>>>>>> the closed port sets > >>>>>>>>>> > >>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>> -DARM > >>>>>>>>>> -DAARCH64 > >>>>>>>>>> > >>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. > >>>>>>>> Whenever > >>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was > >> referring > >>>> to > >>>>>>>> our > >>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open > >> Aarch64 > >>>>>> port. > >>>>>>>>>> > >>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. > >>>>>>>>>> > >>>>>>>>>> We need to keep a clear distinction. Using the combination of > >>>> AARCH64 > >>>>>>>>>> and ARM is not so clear. > >>>>>>>>>> > >>>>>>>>>> You could easily have similar issues with other port groups - eg > >> ppc64 > >>>>>>>>>> vs ppc32 vs ppcle. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> I don't know about the closed stuff, but aarch came up > recently, > >>>> and > >>>>>>>>>>> before that it sure was equivalent. And it still is the case for > >>>> openJDK. > >>>>>>>>>>> > >>>>>>>>>>> Below output is grepped out of the > make//platform_ > >>>> files > >>>>>> in > >>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined > >> twice. > >>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >> D_GNU_SOURCE > >>>> - > >>>>>>>>>> DAMD64 > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >> D_GNU_SOURCE > >>>> - > >>>>>>>> DIA32 > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - > >>>> DCC_INTERP > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DCC_INTERP - > >>>>>> DZERO - > >>>>>>>>>> D at ZERO_ARCHDEF@ - > DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > >> DAMD64 > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > DIA32 > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - > >>>>>>>>>> D at ZERO_ARCHDEF@ - > DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >>>> Barrett > >>>>>>>>>>>> > >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any > further > >>>>>> issues, > >>>>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>>>> > >>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen > in > >> this > >>>>>> new > >>>>>>>>>>>> webrev: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined > >>>>>>>>>>>>> at the same time. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>>>> > >>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This > >> kind > >>>> of > >>>>>>>>>>>> workaround is obscure - you have to know that the Open > >> Aarch64 > >>>>>> port > >>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the > Open > >>>> port > >>>>>>>> use > >>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just > >>>>>> something > >>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> > >>>>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>>>> Barrett > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > files. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should > be > >>>> fixed > >>>>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. > :) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value > >> for > >>>> the > >>>>>>>> ifdef > >>>>>>>>>> is > >>>>>>>>>>>> not > >>>>>>>>>>>>>>> going to work for our closed ports, unless I change that > >> value > >>>> to > >>>>>>>>>> match > >>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to > other > >>>>>>>> problems > >>>>>>>>>> as > >>>>>>>>>>>>>>> we also need that value the way it is currently defined. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H > macro. > >> In > >>>>>>>> general > >>>>>>>>>> you > >>>>>>>>>>>>>> can't just replace: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> with > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our > >> case > >>>>>> ARM > >>>>>>>>>> and > >>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In > contrast > >>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen > to > >>>>>>>> represent > >>>>>>>>>> the > >>>>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> David > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>>> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it > appends > >>>> .hpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >> CPU_HEADER_H, > >>>>>> that > >>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > >> used > >>>>>> only > >>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do > it > >> to > >>>> get > >>>>>> is > >>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names > need > >> not > >>>>>> be > >>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this > needs > >> to > >>>> be > >>>>>> an > >>>>>>>> if- > >>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in > >>>>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>>>> in the same statement as the > INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from > the > >>>> closed > >>>>>>>> part > >>>>>>>>>> of > >>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So > we > >> get > >>>>>> both > >>>>>>>>>>>> defined > >>>>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to > >>>> understand > >>>>>>>> what > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to > >> be, > >>>> as > >>>>>> we > >>>>>>>>>> are > >>>>>>>>>>>> not > >>>>>>>>>>>>>>>>> overriding it for our port - which I think is the current > >>>> problem, > >>>>>>>> but > >>>>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; > >>>>>> Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>> ; > >>>>>>>> Kim > >>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>> hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>> platform > >>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz > >> wrote: > >>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications > and > >>>>>>>> comments > >>>>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch > >> directory, > >>>> but > >>>>>> I > >>>>>>>>>> don't > >>>>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. > >>>> (Sorry I > >>>>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what > needs > >> to > >>>>>> be > >>>>>>>>>>>> changed > >>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this > :).) > >>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory > that > >> has > >>>>>> the > >>>>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 > >>>> header > >>>>>>>> files if > >>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches > >>>>>> internally > >>>>>>>> for > >>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not > >> hold: > >>>>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was > a > >>>>>> common > >>>>>>>> file > >>>>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to > avoid > >> this > >>>>>> kind > >>>>>>>> of > >>>>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in > >> TARGET_SO... > >>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be > moved > >> to > >>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be > >>>> elided > >>>>>>>> here ?? > >>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is > the > >>>>>>>> umbrella > >>>>>>>>>>>> header > >>>>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it > appends > >>>> .hpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >> CPU_HEADER_H, > >>>>>> that > >>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be > >> used > >>>>>> only > >>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do > it > >> to > >>>> get > >>>>>> is > >>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names > need > >> not > >>>>>> be > >>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this > needs > >> to > >>>> be > >>>>>> an > >>>>>>>> if- > >>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of > WINDOWS? Is > >>>> that > >>>>>>>>>> coming > >>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined > >>>>>> WINDOWS > >>>>>>>> in > >>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is > >> defining > >>>> - > >>>>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. > >>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, > >> but > >>>> not > >>>>>> in > >>>>>>>> this > >>>>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the > >>>> unused > >>>>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty > file. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>> ; > >>>>>>>> Kim > >>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>>>> hotspot- > >>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>> platform > >>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz > >> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's > >> working > >>>> on > >>>>>> all > >>>>>>>> the > >>>>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the > >>>> macros > >>>>>> and > >>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name > >>>>>>>> construction > >>>>>>>>>> are > >>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in > >> macros.hpp. > >>>> But > >>>>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and > uses > >>>> the > >>>>>>>> very > >>>>>>>>>>>> same > >>>>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could > >> include > >>>>>> that > >>>>>>>> in > >>>>>>>>>> the > >>>>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as > >> fine > >>>>>> with > >>>>>>>> your > >>>>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is > that > >>>> the > >>>>>>>> linux=1 > >>>>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros > should > >> be > >>>>>>>> upper > >>>>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >>>> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; > >> hotspot- > >>>>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > including > >>>>>>>> platform > >>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, > >> Goetz > >>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these > macros > >> are > >>>>>> only > >>>>>>>>>> used > >>>>>>>>>>>>>> within > >>>>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody > >> needs > >>>> to > >>>>>>>>>>>> understand > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp > >> and > >>>>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu > >>>>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to > >>>> spend > >>>>>> days > >>>>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted > my > >>>>>> current > >>>>>>>>>>>> progress > >>>>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to > do > >> is > >>>>>> adding > >>>>>>>> the > >>>>>>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the > includes. > >>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker > >>>>>> proposed > >>>>>>>> in > >>>>>>>>>> that > >>>>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email > >> thread > >>>> for > >>>>>>>> me; it > >>>>>>>>>>>> looks > >>>>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- > compiler- > >> dev > >>>> but > >>>>>>>> not > >>>>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list > >> this > >>>>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. > I've > >>>> only > >>>>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can > >> wait > >>>>>> until > >>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- > --- > >> --- > >>>> ---- > >>>>>> --- > >>>>>>>> ---- > >>>>>>>>>> --- > >>>>>>>>>>>> --- > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround > existing > >>>>>> #defines > >>>>>>>>>> that > >>>>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so > far: > >>>>>> linux=1, > >>>>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the > >> leading > >>>>>>>>>> underscore > >>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in > >>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>>>>>> > >>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the > >> values. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written > as > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>> > >> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>> > >> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>> > XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets > >>>> instead > >>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) > are > >>>>>> defined, > >>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that > >>>>>> underscore > >>>>>>>>>>>>>> followed > >>>>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word > >>>> pattern > >>>>>>>> for > >>>>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use > >> uppercase > >>>> for > >>>>>>>> the > >>>>>>>>>>>> macro > >>>>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- > --- > >> --- > >>>> ---- > >>>>>> --- > >>>>>>>> ---- > >>>>>>>>>> --- > >>>>>>>>>>>> --- > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> From thomas.schatzl at oracle.com Thu Jul 21 11:28:01 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 21 Jul 2016 13:28:01 +0200 Subject: RFR (S): 8161993: 8161993: G1 crashes if active_processor_count changes during startup Message-ID: <1469100481.4338.18.camel@oracle.com> Hi all, ? can I have reviews for this small change that fixes crashes with G1 when changing the number of available processors while running? The problem is that some data structures are allocated using the number of available processors at startup, and if you later change that number (i.e. increase it), g1 uses indices to access these data structures beyond their capacity. The problem is in?DirtyCardQueueSet::num_par_ids() that re-queries the number of active processors, and then is used e.g. in G1FromCardCache to index an array. The proposed solution is to introduce an initial_active_processor_count() in the runtime that stays fixed after initialization. This corresponds to the suggestion in?JDK-8147910, but only fixing the immediate crash here. I would like to have reviewers from both the gc and runtime team for this change; I cc'ed both mailing lists. CR: https://bugs.openjdk.java.net/browse/JDK-8161993 Webrev: http://cr.openjdk.java.net/~tschatzl/8161993/webrev/ Testing: manual testing, jprt, running vm.gc right now Thanks, ? Thomas From Alan.Burlison at oracle.com Thu Jul 21 12:27:21 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 21 Jul 2016 13:27:21 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed Message-ID: <5790BFA9.9010306@oracle.com> David Holmes pointed out to me that there were instances of __USE_LEGACY_PROTOTYPES__ in Solaris-related code that were redundant, this patch removes them. Bug: https://bugs.openjdk.java.net/browse/JDK-8161601 Webrev: http://sthjprt.uk.oracle.com/archives/2016/07 All JPRT tests were successful. -- Alan Burlison -- From david.holmes at oracle.com Thu Jul 21 12:31:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2016 22:31:29 +1000 Subject: RFR (S): 8161993: 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <1469100481.4338.18.camel@oracle.com> References: <1469100481.4338.18.camel@oracle.com> Message-ID: <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> Hi Thomas, On 21/07/2016 9:28 PM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change that fixes crashes with G1 > when changing the number of available processors while running? > > The problem is that some data structures are allocated using the number > of available processors at startup, and if you later change that number > (i.e. increase it), g1 uses indices to access these data structures > beyond their capacity. > > The problem is in DirtyCardQueueSet::num_par_ids() that re-queries the > number of active processors, and then is used e.g. in G1FromCardCache > to index an array. To be clear num_par_ids() queries the number of configured processors which is constant across the life of the VM. But the number of parallel GC threads is determined by the number of active processors available to the VM - that value may be less than the number of configured processors. (The fact it can change over time doesn't seem to be a factor here - only that it may be smaller.) > > The proposed solution is to introduce an > initial_active_processor_count() in the runtime that stays fixed after > initialization. This corresponds to the suggestion in JDK-8147910, but > only fixing the immediate crash here. I'm not really seeing what else JDK-8147910 would want to add other than reporting the initial count in the error reporting, so I'd rather see this split into two parts - and have both issues closed out. All that would involve is committing the os.hpp and os.cpp and any change to error reporting under 8147910, and the rest under 8161993. A single review thread and combined push is still fine. That said I would not hide this inside os::set_processor_count the way you have. I can see you have done it to avoid changing all the os_xxx.cpp files, but the name no longer really fits as it is not a simple setter operation any more, and it is odd to pass in one value but then internally pull the other one. Albeit more work I would have added set_initial_active_processor_count(int initial) and initial_active_processor_count(), then have the OS initialization methods call both set_processor_count and set_initial_active_processor_count. Or it may be there is somewhere in the shared os initialization code we could add that, once, before it needs to be used for the worker thread calculation. I'd have to look at that in more detail tomorrow. Also if we log the initial_active_count we should log the _processor_count too. Thanks, David > I would like to have reviewers from both the gc and runtime team for > this change; I cc'ed both mailing lists. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8161993 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8161993/webrev/ > Testing: > manual testing, jprt, running vm.gc right now > > Thanks, > Thomas > From claes.redestad at oracle.com Thu Jul 21 12:34:42 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 Jul 2016 14:34:42 +0200 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5790BFA9.9010306@oracle.com> References: <5790BFA9.9010306@oracle.com> Message-ID: <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> Hi, this sounds great, but it seems your webrev lies elsewhere. /Claes Alan Burlison skrev: (21 juli 2016 14:27:21 CEST) >David Holmes pointed out to me that there were instances of >__USE_LEGACY_PROTOTYPES__ in Solaris-related code that were redundant, >this patch removes them. > >Bug: >https://bugs.openjdk.java.net/browse/JDK-8161601 > >Webrev: >http://sthjprt.uk.oracle.com/archives/2016/07 > >All JPRT tests were successful. > >-- >Alan Burlison >-- -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From Alan.Burlison at oracle.com Thu Jul 21 12:40:38 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 21 Jul 2016 13:40:38 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> Message-ID: <5790C2C6.3090302@oracle.com> On 21/07/2016 13:34, Claes Redestad wrote: > Hi, this sounds great, but it seems your webrev lies elsewhere. >> Webrev: >> http://sthjprt.uk.oracle.com/archives/2016/07 Oops, sorry - cut+paste boo-boo - that's the JPRT results ;-) http://cr.openjdk.java.net/~alanbur/JDK-8161601 -- Alan Burlison -- From thomas.schatzl at oracle.com Thu Jul 21 13:05:05 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 21 Jul 2016 15:05:05 +0200 Subject: RFR (S): 8161993: 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> Message-ID: <1469106305.4338.24.camel@oracle.com> Hi David, ? thanks for your review. On Thu, 2016-07-21 at 22:31 +1000, David Holmes wrote: > Hi Thomas, > > On 21/07/2016 9:28 PM, Thomas Schatzl wrote: > > > > Hi all, > > > > ? can I have reviews for this small change that fixes crashes with > > G1 when changing the number of available processors while running? > > > > The problem is that some data structures are allocated using the > > number > > of available processors at startup, and if you later change that > > number > > (i.e. increase it), g1 uses indices to access these data structures > > beyond their capacity. > > > > The problem is in DirtyCardQueueSet::num_par_ids() that re-queries > > the number of active processors, and then is used e.g. in > > G1FromCardCache to index an array. > To be clear num_par_ids() queries the number of configured processors > which is constant across the life of the VM. But the number of > parallel GC threads is determined by the number of active processors > available to the VM - that value may be less than the number of > configured processors. (The fact it can change over time doesn't seem > to be a factor here - only that it may be smaller.) > > > > > > > The proposed solution is to introduce an > > initial_active_processor_count() in the runtime that stays fixed > > after initialization. This corresponds to the suggestion in JDK- > > 8147910, but only fixing the immediate crash here. > I'm not really seeing what else JDK-8147910 would want to add other > than reporting the initial count in the error reporting, so I'd > rather see this split into two parts - and have both issues closed > out. All that would involve is committing the os.hpp and os.cpp and > any change to error reporting under 8147910, and the rest under > 8161993. A single review thread and combined push is still fine. Okay, can do the split of this CR into two. I briefly looked through the hs_err log file, but could not find any particular section where this information would fit well. Any suggestions? > That said I would not hide this inside os::set_processor_count the > way you have. I can see you have done it to avoid changing all the? > os_xxx.cpp files, but the name no longer really fits as it is not a? > simple setter operation any more, and it is odd to pass in one value > but then internally pull the other one. Albeit more work I would have > added set_initial_active_processor_count(int initial) and? > initial_active_processor_count(), then have the OS initialization? > methods call both set_processor_count and? > set_initial_active_processor_count. Or it may be there is somewhere > in the shared os initialization code we could add that, once, before > it needs to be used for the worker thread calculation. I'd have to > look at that in more detail tomorrow. The call could be put in the os::init_before_ergo() (or VMVersion::init_before_ergo()) call. I would prefer to avoid code duplication. > Also if we log the initial_active_count we should log the? > _processor_count too. I can log both in log messages and the error log - although processor count information is already in the log. Thanks, ? Thomas From claes.redestad at oracle.com Thu Jul 21 15:12:07 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 Jul 2016 17:12:07 +0200 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5790C2C6.3090302@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> Message-ID: <5790E647.2050503@oracle.com> On 2016-07-21 14:40, Alan Burlison wrote: > On 21/07/2016 13:34, Claes Redestad wrote: > >> Hi, this sounds great, but it seems your webrev lies elsewhere. > >>> Webrev: >>> http://sthjprt.uk.oracle.com/archives/2016/07 > > Oops, sorry - cut+paste boo-boo - that's the JPRT results ;-) > > http://cr.openjdk.java.net/~alanbur/JDK-8161601 > FWIW, change looks reasonable to me, but you may want someone from the runtime team to give this their blessing. Thanks! /Claes From harold.seigel at oracle.com Thu Jul 21 15:25:11 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 21 Jul 2016 11:25:11 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <578E6CBC.9010901@oracle.com> References: <578E6CBC.9010901@oracle.com> Message-ID: Hi Lois, This is a nice fix for the exploded build system class path issues! If the callers of methods such as add_to_exploded_build_list() already have THREAD, can it be passed as a parameter? In classLoader.cpp, the comment at lines 1466 - 1468 say that the starting classpath_index is always 1. Can you either add an assert for this or change line 1469 to just: classpath_index = 1; In classLoader.hpp, could has_jimage() be renamed to something like has_jrt_entry so it's not confused with the has_jimage() method in arguments.hpp? In filemap.cpp, can the code at lines 226 - 230 be changed to: assert(strptr + name_bytes <= strptr_max, "miscalculated buffer size"); strncpy(...) strptr += name_bytes; Thanks, Harold On 7/19/2016 2:09 PM, Lois Foltan wrote: > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ > > Bug: -Xbootclasspath/a breaks exploded build > https://bugs.openjdk.java.net/browse/JDK-8154239 > > Summary: > The JVM was incorrectly handling how to set up and search the > ClassPathEntry's for directories representing the module definitions > in an exploded module build situation for the boot class loader. The > incorrect set up and search was particularly exposed when > -Xbootclasspath/a was specified in conjunction with a exploded module > build. In an exploded module build, when Modules::define_modules was > called to define a module to the boot loader, a ClassPathEntry was > simply appended to the boot loader's search list. At load class time, > a class would then be searched by simply traversing that list without > any regards to the module that class was defined in. This is > incorrect behavior. The class should only be searched for in the > location of the module's definition that it was defined within. The > fix now records each module and it's exploded build location in order > to adhere to this rule. > > The other piece to this problem was that if -Xbootclasspath/a was > specified, it was incorrectly injected prior to the majority of > ClassPathEntry's for the exploded modules, yielding a broken and > incorrect search order for the boot loader. Introducing the concept > of a "base" or "core" piece for the boot loader which is either the > java runtime image or the exploded modules build and changing the > ClassLoader::_first_append_entry to truly be only appended entries > added via -Xbootclasspath/a or jvmti appended entries, introduces a > clean way for how this information is stored in the ClassLoader data > structure that maps directly to how ClassLoader::load_class() searches > that information. > > 215 // The boot class path consists of 3 ordered pieces: > 216 // 1. the module/path pairs specified to -Xpatch > 217 // -Xpatch:=()* > 218 // 2. the base piece > 219 // [jimage | build with exploded modules] > 220 // 3. boot loader append path > 221 // [-Xbootclasspath/a]; [jvmti appended entries] > 222 // > 223 // The boot loader must obey this order when attempting > 224 // to load a class. > > > Testing: > Full hotspot nightly testing with a java runtime image build > JDK java/io, java/lang, java/util with both a java runtime image and > an exploded module build > JCK lang & vm with both a java runtime image and an exploded module build > Hotspot jtreg tests with both a java runtime image and an exploded > module build > From daniel.daugherty at oracle.com Thu Jul 21 16:02:08 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Jul 2016 10:02:08 -0600 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5790BFA9.9010306@oracle.com> References: <5790BFA9.9010306@oracle.com> Message-ID: Adding Jerry T explicitly to this review thread... On 7/21/16 6:27 AM, Alan Burlison wrote: > David Holmes pointed out to me that there were instances of > __USE_LEGACY_PROTOTYPES__ in Solaris-related code that were redundant, > this patch removes them. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8161601 > > Webrev: > http://sthjprt.uk.oracle.com/archives/2016/07 > > All JPRT tests were successful. > > http://cr.openjdk.java.net/~alanbur/JDK-8161601 General comment Please update copyright years as appropriate. hotspot/src/os/solaris/vm/jvm_solaris.h No comments. hotspot/src/os/solaris/vm/perfMemory_solaris.cpp No comments. hotspot/src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Interesting removal of ; reducing the scope of places that get this include? (good idea) hotspot/src/closed/os/solaris/vm/os_perf_solaris.cpp No comments. Thumbs up. I believe the __USE_LEGACY_PROTOTYPES__ uses around were added by Jerry Thornbrugh when our official build platform was Solaris 10u6 or something like that. Dan P.S. Alan, I'll setup a repo for pushing this changeset when you get through the review process. From gerald.thornbrugh at oracle.com Thu Jul 21 17:11:40 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Thu, 21 Jul 2016 11:11:40 -0600 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> Message-ID: <8C4DC779-6A85-4CF3-90EF-9E1795993CB2@oracle.com> Hi Dan and Alan, Yes, I added the ?__USE_LEGACY_PROTOTYPE__? statements as part of a change when the Solaris supported build platform was something like S10u6. These changes look good to me. Thanks! Jerry > On Jul 21, 2016, at 10:02 AM, Daniel D. Daugherty wrote: > > Adding Jerry T explicitly to this review thread... > > On 7/21/16 6:27 AM, Alan Burlison wrote: >> David Holmes pointed out to me that there were instances of __USE_LEGACY_PROTOTYPES__ in Solaris-related code that were redundant, this patch removes them. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8161601 >> >> Webrev: >> http://sthjprt.uk.oracle.com/archives/2016/07 >> >> All JPRT tests were successful. >> > > > http://cr.openjdk.java.net/~alanbur/JDK-8161601 > > General comment > > Please update copyright years as appropriate. > > > hotspot/src/os/solaris/vm/jvm_solaris.h > No comments. > > hotspot/src/os/solaris/vm/perfMemory_solaris.cpp > No comments. > > hotspot/src/share/vm/utilities/globalDefinitions_sparcWorks.hpp > Interesting removal of ; reducing the scope of places > that get this include? (good idea) > > hotspot/src/closed/os/solaris/vm/os_perf_solaris.cpp > No comments. > > Thumbs up. > > I believe the __USE_LEGACY_PROTOTYPES__ uses around > were added by Jerry Thornbrugh when our official build platform > was Solaris 10u6 or something like that. > > Dan > > P.S. > Alan, I'll setup a repo for pushing this changeset when you > get through the review process. From karen.kinnear at oracle.com Thu Jul 21 17:23:12 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 21 Jul 2016 13:23:12 -0400 Subject: RFR: JDK-8162340: Better class stream parsing Message-ID: Please review: https://bugs.openjdk.java.net/browse/JDK-8162340 http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev When moving the check from resolve_from_stream to set_package, I removed the no longer need parsed_class (!) which I should have cleaned up when tightening the placeholder table cleanup years ago. Tests run: 1. updated VMAnonymousClass test 2. jcks 3. rbt hs-nightly-runtime linux-x64 in progress thanks, Karen From harold.seigel at oracle.com Thu Jul 21 17:39:40 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 21 Jul 2016 13:39:40 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: <42087f8a-d808-92a5-303a-35eabf5b0843@oracle.com> Hi Coleen, Thank you for reviewing my changes! Please see comments inline. On 7/20/2016 5:47 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/src/share/vm/runtime/arguments.cpp.udiff.html > > > To check if is_internal_module_property, the numbered ones go to > is_matching_numbered_property, but do you also want to disallow: > > jdk.module.addreads.foo or jdk.module.addreads (with no number?) We don't ignore properties like these because they do not have special meaning to the jdk. I didn't want to ignore properties just because they are very similar to ones that do get ignored. > > Why aren't addmods and limitmods allowed be specified more than once > on the command line and handled like the other ones? Please see Alan's response. Should I open an RFE for allowing multiple --add-modules options? > > + // options. For example: use "--add-modules java.sql", not > "-Djdk.module.addmods=java.sql" > > Does this comment need an equal sign? Yes, done. > > http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/test/compiler/unsafe/UnsafeGetConstantField.java.udiff.html > > > Can you fix the indentation? Done. > > We should add an option -XX:+UseUnsafe to be a shortcut for this: > > --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED Please see Alan's response. > > > > The rest looks good. This implementation looks very clean. Thanks! Harold > > Thanks, > Coleen > > > On 7/17/16 7:05 PM, harold seigel wrote: >> Hi, >> >> Please review these Hotspot VM only changes to process the seven >> module-specific options that have been renamed to have gnu-like >> names. JDK changes for this bug will be reviewed separately. >> >> Descriptions of these options are here >> . For these six options, >> --module-path, --upgrade-module-path, --add-modules, --limit-modules, >> --add-reads, and --add-exports, the JVM just sets a system property. >> For the --patch-module option, the JVM sets a system property and >> then processes the option in the same way as when it was named -Xpatch. >> >> Additionally, the JVM now checks properties specified on the command >> line. If a property matches one of the properties used by one of the >> above options then the JVM ignores the property. This forces users to >> use the explicit option when wanting to do things like add a module >> or a package export. >> >> The RFR contains two new tests. Also, many existing tests were >> changed to use the new option names. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >> >> The changes were tested with the JCK lang and VM tests, the JTreg >> hotspot tests, and the RBT hotspot nightlies. >> >> Thanks, Harold > From calvin.cheung at oracle.com Thu Jul 21 19:02:11 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Jul 2016 12:02:11 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM Message-ID: <57911C33.3000404@oracle.com> Summary of change: - removes the dummy jvmti function bodies in instanceKlass.hpp; - put "#if INCLUDE_JVMTI" guards at the call sites of those functions. bug: https://bugs.openjdk.java.net/browse/JDK-8161539 webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ It passed JPRT and "tier-2" testing. It also passed minimal vm build. thanks, Calvin From gerard.ziemski at oracle.com Thu Jul 21 19:23:45 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 21 Jul 2016 14:23:45 -0500 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <57911C33.3000404@oracle.com> References: <57911C33.3000404@oracle.com> Message-ID: <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> hi Calvin. Looks good, (r)eviewed. cheers > On Jul 21, 2016, at 2:02 PM, Calvin Cheung wrote: > > > Summary of change: > - removes the dummy jvmti function bodies in instanceKlass.hpp; > - put "#if INCLUDE_JVMTI" guards at the call sites of those functions. > > bug: https://bugs.openjdk.java.net/browse/JDK-8161539 > webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ > > It passed JPRT and "tier-2" testing. > It also passed minimal vm build. > > thanks, > Calvin From lois.foltan at oracle.com Thu Jul 21 19:31:24 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 21 Jul 2016 15:31:24 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: References: Message-ID: <5791230C.8080904@oracle.com> Hi Karen, This looks good and is cleaner calling check_prohibited_package from set_package. Thanks, Lois On 7/21/2016 1:23 PM, Karen Kinnear wrote: > Please review: > https://bugs.openjdk.java.net/browse/JDK-8162340 > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ > http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev > > When moving the check from resolve_from_stream to set_package, I removed > the no longer need parsed_class (!) which I should have cleaned up when > tightening the placeholder table cleanup years ago. > > Tests run: > 1. updated VMAnonymousClass test > 2. jcks > 3. rbt hs-nightly-runtime linux-x64 in progress > > thanks, > Karen > > From coleen.phillimore at oracle.com Thu Jul 21 19:32:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 15:32:28 -0400 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> Message-ID: Hi Calvin, I really don't like these conditionals. Why take the functions out of the #else in instanceKlass.hpp? thanks, Coleen On 7/21/16 3:23 PM, Gerard Ziemski wrote: > hi Calvin. > > Looks good, (r)eviewed. > > > cheers > >> On Jul 21, 2016, at 2:02 PM, Calvin Cheung wrote: >> >> >> Summary of change: >> - removes the dummy jvmti function bodies in instanceKlass.hpp; >> - put "#if INCLUDE_JVMTI" guards at the call sites of those functions. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >> >> It passed JPRT and "tier-2" testing. >> It also passed minimal vm build. >> >> thanks, >> Calvin From Alan.Burlison at oracle.com Thu Jul 21 19:39:04 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 21 Jul 2016 20:39:04 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5790E647.2050503@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <5790E647.2050503@oracle.com> Message-ID: <579124D8.1010907@oracle.com> On 21/07/2016 16:12, Claes Redestad wrote: > FWIW, change looks reasonable to me, but you may want someone > from the runtime team to give this their blessing. Which mailing list, or are they on this one? -- Alan Burlison -- From calvin.cheung at oracle.com Thu Jul 21 19:44:53 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Jul 2016 12:44:53 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> Message-ID: <57912635.4030601@oracle.com> Hi Coleen, On 7/21/16, 12:32 PM, Coleen Phillimore wrote: > Hi Calvin, > > I really don't like these conditionals. > > Why take the functions out of the #else in instanceKlass.hpp? The idea is to catch this kind of problem during build time, not during runtime. thanks, Calvin > > thanks, > Coleen > > On 7/21/16 3:23 PM, Gerard Ziemski wrote: >> hi Calvin. >> >> Looks good, (r)eviewed. >> >> >> cheers >> >>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>> wrote: >>> >>> >>> Summary of change: >>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>> - put "#if INCLUDE_JVMTI" guards at the call sites of those functions. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>> >>> It passed JPRT and "tier-2" testing. >>> It also passed minimal vm build. >>> >>> thanks, >>> Calvin > From Alan.Burlison at oracle.com Thu Jul 21 19:47:59 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 21 Jul 2016 20:47:59 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> Message-ID: <579126EF.60701@oracle.com> On 21/07/2016 17:02, Daniel D. Daugherty wrote: > General comment > > Please update copyright years as appropriate. Oops sorry - of course - done. Webrev updated. > hotspot/src/share/vm/utilities/globalDefinitions_sparcWorks.hpp > Interesting removal of ; reducing the scope of places > that get this include? (good idea) Yes, nothing from it was being used in the source file so I figured removing it altogether was best. > P.S. > Alan, I'll setup a repo for pushing this changeset when you > get through the review process. Thanks :-) -- Alan Burlison -- From chris.plummer at oracle.com Thu Jul 21 20:01:40 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 21 Jul 2016 13:01:40 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <57911C33.3000404@oracle.com> References: <57911C33.3000404@oracle.com> Message-ID: <370148d4-496a-8de0-aab3-be334ee74678@oracle.com> See my comments in the CR. I don't think all these changes should be necessary. thanks, Chris On 7/21/16 12:02 PM, Calvin Cheung wrote: > > Summary of change: > - removes the dummy jvmti function bodies in instanceKlass.hpp; > - put "#if INCLUDE_JVMTI" guards at the call sites of those functions. > > bug: https://bugs.openjdk.java.net/browse/JDK-8161539 > webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ > > It passed JPRT and "tier-2" testing. > It also passed minimal vm build. > > thanks, > Calvin From coleen.phillimore at oracle.com Thu Jul 21 20:19:38 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 16:19:38 -0400 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <57912635.4030601@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> Message-ID: <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> On 7/21/16 3:44 PM, Calvin Cheung wrote: > Hi Coleen, > > On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >> Hi Calvin, >> >> I really don't like these conditionals. >> >> Why take the functions out of the #else in instanceKlass.hpp? > The idea is to catch this kind of problem during build time, not > during runtime. If you want to catch this as buildtime, then take set_cached_class_file() out of the #else part and do Chris's suggested fix (which is a smaller version of Ioi's fix). We really don't want #ifdefs sprinkled around the vm for the minimal vm. Especially not in ClassLoaderData.cpp. Coleen > > thanks, > Calvin >> >> thanks, >> Coleen >> >> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>> hi Calvin. >>> >>> Looks good, (r)eviewed. >>> >>> >>> cheers >>> >>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>> wrote: >>>> >>>> >>>> Summary of change: >>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those functions. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>> >>>> It passed JPRT and "tier-2" testing. >>>> It also passed minimal vm build. >>>> >>>> thanks, >>>> Calvin >> From daniel.daugherty at oracle.com Thu Jul 21 20:23:46 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Jul 2016 14:23:46 -0600 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <579124D8.1010907@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <5790E647.2050503@oracle.com> <579124D8.1010907@oracle.com> Message-ID: On 7/21/16 1:39 PM, Alan Burlison wrote: > On 21/07/2016 16:12, Claes Redestad wrote: > >> FWIW, change looks reasonable to me, but you may want someone >> from the runtime team to give this their blessing. > > Which mailing list, or are they on this one? > The hotspot-runtime-dev at openjdk.java.net list that you used is the right list. Also you have my (R)eview and I'm on the Runtime team... Dan From calvin.cheung at oracle.com Thu Jul 21 20:49:50 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Jul 2016 13:49:50 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> Message-ID: <5791356E.8070303@oracle.com> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: > > > On 7/21/16 3:44 PM, Calvin Cheung wrote: >> Hi Coleen, >> >> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>> Hi Calvin, >>> >>> I really don't like these conditionals. >>> >>> Why take the functions out of the #else in instanceKlass.hpp? >> The idea is to catch this kind of problem during build time, not >> during runtime. > > If you want to catch this as buildtime, then take > set_cached_class_file() out of the #else part and do Chris's suggested > fix (which is a smaller version of Ioi's fix). If we're leaving the other functions in the #else part, I think we should leave the set_cached_class_file() there as well. I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. What do you think? thanks, Calvin > > We really don't want #ifdefs sprinkled around the vm for the minimal > vm. Especially not in ClassLoaderData.cpp. > > Coleen > >> >> thanks, >> Calvin >>> >>> thanks, >>> Coleen >>> >>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>> hi Calvin. >>>> >>>> Looks good, (r)eviewed. >>>> >>>> >>>> cheers >>>> >>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>> wrote: >>>>> >>>>> >>>>> Summary of change: >>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>> functions. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>> >>>>> It passed JPRT and "tier-2" testing. >>>>> It also passed minimal vm build. >>>>> >>>>> thanks, >>>>> Calvin >>> > From coleen.phillimore at oracle.com Thu Jul 21 21:05:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 17:05:17 -0400 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <5791356E.8070303@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> Message-ID: <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> On 7/21/16 4:49 PM, Calvin Cheung wrote: > > > On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >> >> >> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>> Hi Coleen, >>> >>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>> Hi Calvin, >>>> >>>> I really don't like these conditionals. >>>> >>>> Why take the functions out of the #else in instanceKlass.hpp? >>> The idea is to catch this kind of problem during build time, not >>> during runtime. >> >> If you want to catch this as buildtime, then take >> set_cached_class_file() out of the #else part and do Chris's >> suggested fix (which is a smaller version of Ioi's fix). > If we're leaving the other functions in the #else part, I think we > should leave the set_cached_class_file() there as well. > I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. > What do you think? Yes, looking at this again, I think Chris's change is fine. You have to leave the definition of this in and cannot get a compile time error. Coleen > > thanks, > Calvin > > > >> >> We really don't want #ifdefs sprinkled around the vm for the minimal >> vm. Especially not in ClassLoaderData.cpp. >> >> Coleen >> >>> >>> thanks, >>> Calvin >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>> hi Calvin. >>>>> >>>>> Looks good, (r)eviewed. >>>>> >>>>> >>>>> cheers >>>>> >>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>> wrote: >>>>>> >>>>>> >>>>>> Summary of change: >>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>> functions. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>> >>>>>> It passed JPRT and "tier-2" testing. >>>>>> It also passed minimal vm build. >>>>>> >>>>>> thanks, >>>>>> Calvin >>>> >> From lois.foltan at oracle.com Thu Jul 21 21:11:46 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 21 Jul 2016 17:11:46 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: References: <578E6CBC.9010901@oracle.com> Message-ID: <57913A92.6040001@oracle.com> On 7/21/2016 11:25 AM, harold seigel wrote: > Hi Lois, > > This is a nice fix for the exploded build system class path issues! > > If the callers of methods such as add_to_exploded_build_list() already > have THREAD, can it be passed as a parameter? Done. > > In classLoader.cpp, the comment at lines 1466 - 1468 say that the > starting classpath_index is always 1. Can you either add an assert > for this or change line 1469 to just: classpath_index = 1; Done. > > In classLoader.hpp, could has_jimage() be renamed to something like > has_jrt_entry so it's not confused with the has_jimage() method in > arguments.hpp? Done. > > In filemap.cpp, can the code at lines 226 - 230 be changed to: > > assert(strptr + name_bytes <= strptr_max, "miscalculated buffer > size"); > strncpy(...) > strptr += name_bytes; Done. Thanks for the review Harold! New webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ Lois > > Thanks, Harold > > > On 7/19/2016 2:09 PM, Lois Foltan wrote: >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >> >> Bug: -Xbootclasspath/a breaks exploded build >> https://bugs.openjdk.java.net/browse/JDK-8154239 >> >> Summary: >> The JVM was incorrectly handling how to set up and search the >> ClassPathEntry's for directories representing the module definitions >> in an exploded module build situation for the boot class loader. The >> incorrect set up and search was particularly exposed when >> -Xbootclasspath/a was specified in conjunction with a exploded module >> build. In an exploded module build, when Modules::define_modules was >> called to define a module to the boot loader, a ClassPathEntry was >> simply appended to the boot loader's search list. At load class >> time, a class would then be searched by simply traversing that list >> without any regards to the module that class was defined in. This is >> incorrect behavior. The class should only be searched for in the >> location of the module's definition that it was defined within. The >> fix now records each module and it's exploded build location in order >> to adhere to this rule. >> >> The other piece to this problem was that if -Xbootclasspath/a was >> specified, it was incorrectly injected prior to the majority of >> ClassPathEntry's for the exploded modules, yielding a broken and >> incorrect search order for the boot loader. Introducing the concept >> of a "base" or "core" piece for the boot loader which is either the >> java runtime image or the exploded modules build and changing the >> ClassLoader::_first_append_entry to truly be only appended entries >> added via -Xbootclasspath/a or jvmti appended entries, introduces a >> clean way for how this information is stored in the ClassLoader data >> structure that maps directly to how ClassLoader::load_class() >> searches that information. >> >> 215 // The boot class path consists of 3 ordered pieces: >> 216 // 1. the module/path pairs specified to -Xpatch >> 217 // -Xpatch:=()* >> 218 // 2. the base piece >> 219 // [jimage | build with exploded modules] >> 220 // 3. boot loader append path >> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >> 222 // >> 223 // The boot loader must obey this order when attempting >> 224 // to load a class. >> >> >> Testing: >> Full hotspot nightly testing with a java runtime image build >> JDK java/io, java/lang, java/util with both a java runtime image and >> an exploded module build >> JCK lang & vm with both a java runtime image and an exploded module >> build >> Hotspot jtreg tests with both a java runtime image and an exploded >> module build >> > From coleen.phillimore at oracle.com Thu Jul 21 21:32:25 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 17:32:25 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <90ad7800-db3b-cf7e-b2ab-1aca4105a570@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <90ad7800-db3b-cf7e-b2ab-1aca4105a570@oracle.com> Message-ID: On 7/21/16 3:25 AM, Alan Bateman wrote: > On 20/07/2016 22:47, Coleen Phillimore wrote: > >> >> >> Why aren't addmods and limitmods allowed be specified more than once >> on the command line and handled like the other ones? > It's last one wins, typical for most options when repeated. I could > imagine someone composing a command line with --add-modules coming > from multiple sources, they logically merge/union, so maybe there is a > case for that. However --limit-modules is niche and I don't think > makes sense to attempt to merge. Well having subtle differences like this makes it difficult to explain to people, and nobody reads documentation in that much detail. It seems like you should try to be consistent, if it makes sense. But no, I don't know what limitmods does or whether you'd want to aggregate this. Coleen > >> >> We should add an option -XX:+UseUnsafe to be a shortcut for this: >> >> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED > That may be useful for JDK tests but it makes it too easy to get to > jdk.internal.misc.Unsafe. For usages outside of the JDK then I think > they should continue to use sun.misc.Unsafe (JEP 260 etc.) and > gradually reduce that over time as better approaches are available in > the platform. > > -Alan From coleen.phillimore at oracle.com Thu Jul 21 21:37:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 17:37:21 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <42087f8a-d808-92a5-303a-35eabf5b0843@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <42087f8a-d808-92a5-303a-35eabf5b0843@oracle.com> Message-ID: <5e3cba15-6126-c526-2c43-9c07f927a5a1@oracle.com> On 7/21/16 1:39 PM, harold seigel wrote: > Hi Coleen, > > Thank you for reviewing my changes! > > Please see comments inline. > > > On 7/20/2016 5:47 PM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/src/share/vm/runtime/arguments.cpp.udiff.html >> >> >> To check if is_internal_module_property, the numbered ones go to >> is_matching_numbered_property, but do you also want to disallow: >> >> jdk.module.addreads.foo or jdk.module.addreads (with no number?) > We don't ignore properties like these because they do not have special > meaning to the jdk. I didn't want to ignore properties just because > they are very similar to ones that do get ignored. Don't we own the jdk.module namespace and from these patterns it's clear that it's an error, although we won't flag it, and somebody might get results that are unexpected. I think you should flag these. >> >> Why aren't addmods and limitmods allowed be specified more than once >> on the command line and handled like the other ones? > Please see Alan's response. Should I open an RFE for allowing > multiple --add-modules options? Yes, and you can discuss it there. >> >> + // options. For example: use "--add-modules java.sql", not >> "-Djdk.module.addmods=java.sql" >> >> Does this comment need an equal sign? > Yes, done. >> >> http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/test/compiler/unsafe/UnsafeGetConstantField.java.udiff.html >> >> >> Can you fix the indentation? > Done. >> >> We should add an option -XX:+UseUnsafe to be a shortcut for this: >> >> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED > Please see Alan's response. I was looking at all the tests and was wondering if there's a way for some other option to imply these -add-exports options, so we wouldn't need so many. But the patterns aren't all the same in all the tests, except the ALL-UNNAMED bit. I've Reviewed this now. Thanks, Coleen >> >> >> >> The rest looks good. This implementation looks very clean. > Thanks! Harold >> >> Thanks, >> Coleen >> >> >> On 7/17/16 7:05 PM, harold seigel wrote: >>> Hi, >>> >>> Please review these Hotspot VM only changes to process the seven >>> module-specific options that have been renamed to have gnu-like >>> names. JDK changes for this bug will be reviewed separately. >>> >>> Descriptions of these options are here >>> . For these six options, >>> --module-path, --upgrade-module-path, --add-modules, >>> --limit-modules, --add-reads, and --add-exports, the JVM just sets a >>> system property. For the --patch-module option, the JVM sets a >>> system property and then processes the option in the same way as >>> when it was named -Xpatch. >>> >>> Additionally, the JVM now checks properties specified on the command >>> line. If a property matches one of the properties used by one of >>> the above options then the JVM ignores the property. This forces >>> users to use the explicit option when wanting to do things like add >>> a module or a package export. >>> >>> The RFR contains two new tests. Also, many existing tests were >>> changed to use the new option names. >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >>> >>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >>> >>> The changes were tested with the JCK lang and VM tests, the JTreg >>> hotspot tests, and the RBT hotspot nightlies. >>> >>> Thanks, Harold >> > From coleen.phillimore at oracle.com Thu Jul 21 21:40:02 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 17:40:02 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <5e3cba15-6126-c526-2c43-9c07f927a5a1@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <42087f8a-d808-92a5-303a-35eabf5b0843@oracle.com> <5e3cba15-6126-c526-2c43-9c07f927a5a1@oracle.com> Message-ID: <6f80496e-8b52-8a6c-5c09-719445635ee8@oracle.com> On 7/21/16 5:37 PM, Coleen Phillimore wrote: > > > On 7/21/16 1:39 PM, harold seigel wrote: >> Hi Coleen, >> >> Thank you for reviewing my changes! >> >> Please see comments inline. >> >> >> On 7/20/2016 5:47 PM, Coleen Phillimore wrote: >>> >>> http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/src/share/vm/runtime/arguments.cpp.udiff.html >>> >>> >>> To check if is_internal_module_property, the numbered ones go to >>> is_matching_numbered_property, but do you also want to disallow: >>> >>> jdk.module.addreads.foo or jdk.module.addreads (with no number?) >> We don't ignore properties like these because they do not have >> special meaning to the jdk. I didn't want to ignore properties just >> because they are very similar to ones that do get ignored. > > Don't we own the jdk.module namespace and from these patterns it's > clear that it's an error, although we won't flag it, and somebody > might get results that are unexpected. > > I think you should flag these. You could make this a follow-on bug. Coleen > >>> >>> Why aren't addmods and limitmods allowed be specified more than once >>> on the command line and handled like the other ones? >> Please see Alan's response. Should I open an RFE for allowing >> multiple --add-modules options? > > Yes, and you can discuss it there. > >>> >>> + // options. For example: use "--add-modules java.sql", not >>> "-Djdk.module.addmods=java.sql" >>> >>> Does this comment need an equal sign? >> Yes, done. >>> >>> http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/test/compiler/unsafe/UnsafeGetConstantField.java.udiff.html >>> >>> >>> Can you fix the indentation? >> Done. >>> >>> We should add an option -XX:+UseUnsafe to be a shortcut for this: >>> >>> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >> Please see Alan's response. > > I was looking at all the tests and was wondering if there's a way for > some other option to imply these -add-exports options, so we wouldn't > need so many. But the patterns aren't all the same in all the tests, > except the ALL-UNNAMED bit. > > I've Reviewed this now. > > Thanks, > Coleen > > >>> >>> >>> >>> The rest looks good. This implementation looks very clean. >> Thanks! Harold >>> >>> Thanks, >>> Coleen >>> >>> >>> On 7/17/16 7:05 PM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review these Hotspot VM only changes to process the seven >>>> module-specific options that have been renamed to have gnu-like >>>> names. JDK changes for this bug will be reviewed separately. >>>> >>>> Descriptions of these options are here >>>> . For these six options, >>>> --module-path, --upgrade-module-path, --add-modules, >>>> --limit-modules, --add-reads, and --add-exports, the JVM just sets >>>> a system property. For the --patch-module option, the JVM sets a >>>> system property and then processes the option in the same way as >>>> when it was named -Xpatch. >>>> >>>> Additionally, the JVM now checks properties specified on the >>>> command line. If a property matches one of the properties used by >>>> one of the above options then the JVM ignores the property. This >>>> forces users to use the explicit option when wanting to do things >>>> like add a module or a package export. >>>> >>>> The RFR contains two new tests. Also, many existing tests were >>>> changed to use the new option names. >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >>>> >>>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >>>> >>>> The changes were tested with the JCK lang and VM tests, the JTreg >>>> hotspot tests, and the RBT hotspot nightlies. >>>> >>>> Thanks, Harold >>> >> > From david.holmes at oracle.com Thu Jul 21 22:00:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2016 08:00:33 +1000 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> Message-ID: <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> I'm going to wait to see what form this takes before additional commenting beyond what is in the bug report. But a shouldNotReachHere() implementation is/was not the intended way to handle these conditionals. Either dummy functions are present and called, or else no functions and the calls are guarded - not some hybrid mix. Thanks, David On 22/07/2016 7:05 AM, Coleen Phillimore wrote: > > > On 7/21/16 4:49 PM, Calvin Cheung wrote: >> >> >> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >>> >>> >>> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>>> Hi Coleen, >>>> >>>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>>> Hi Calvin, >>>>> >>>>> I really don't like these conditionals. >>>>> >>>>> Why take the functions out of the #else in instanceKlass.hpp? >>>> The idea is to catch this kind of problem during build time, not >>>> during runtime. >>> >>> If you want to catch this as buildtime, then take >>> set_cached_class_file() out of the #else part and do Chris's >>> suggested fix (which is a smaller version of Ioi's fix). >> If we're leaving the other functions in the #else part, I think we >> should leave the set_cached_class_file() there as well. >> I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. >> What do you think? > > Yes, looking at this again, I think Chris's change is fine. You have to > leave the definition of this in and cannot get a compile time error. > > Coleen > >> >> thanks, >> Calvin >> >> >> >>> >>> We really don't want #ifdefs sprinkled around the vm for the minimal >>> vm. Especially not in ClassLoaderData.cpp. >>> >>> Coleen >>> >>>> >>>> thanks, >>>> Calvin >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>>> hi Calvin. >>>>>> >>>>>> Looks good, (r)eviewed. >>>>>> >>>>>> >>>>>> cheers >>>>>> >>>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Summary of change: >>>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>>> functions. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>>> >>>>>>> It passed JPRT and "tier-2" testing. >>>>>>> It also passed minimal vm build. >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>> >>> > From john.r.rose at oracle.com Thu Jul 21 22:16:17 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 21 Jul 2016 15:16:17 -0700 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: References: Message-ID: <3C496818-AAC5-4FE3-BABB-F5A767B7B8D4@oracle.com> Excellent. Thanks for chasing down all the details. The cleanups are welcome, and the principled restriction on loading into the "java/" packages will help us sleep at night. Reviewed. ? John On Jul 21, 2016, at 10:23 AM, Karen Kinnear wrote: > > Please review: > https://bugs.openjdk.java.net/browse/JDK-8162340 > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ > http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev > > When moving the check from resolve_from_stream to set_package, I removed > the no longer need parsed_class (!) which I should have cleaned up when > tightening the placeholder table cleanup years ago. > > Tests run: > 1. updated VMAnonymousClass test > 2. jcks > 3. rbt hs-nightly-runtime linux-x64 in progress > > thanks, > Karen > > From Alan.Burlison at oracle.com Thu Jul 21 22:39:58 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 21 Jul 2016 23:39:58 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <5790E647.2050503@oracle.com> <579124D8.1010907@oracle.com> Message-ID: <57914F3E.4060500@oracle.com> On 21/07/2016 21:23, Daniel D. Daugherty wrote: > The hotspot-runtime-dev at openjdk.java.net list that you used is the right > list. Also you have my (R)eview and I'm on the Runtime team... Good-oh, thanks :-) -- Alan Burlison -- From coleen.phillimore at oracle.com Thu Jul 21 22:45:27 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 18:45:27 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: References: Message-ID: http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html +// Handles unsafe_DefineAnonymousClass and redefineclasses +// redefinedclasses do not add to the class hierarchy Can you change /redefineclasses/RedefineClasses/? We pattern match on this. Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html Awesome! I'm glad you found this comment to remove. Nobody's going to miss parsed_name. This is a nice change! Thanks, Coleen On 7/21/16 1:23 PM, Karen Kinnear wrote: > Please review: > https://bugs.openjdk.java.net/browse/JDK-8162340 > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ > http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev > > When moving the check from resolve_from_stream to set_package, I removed > the no longer need parsed_class (!) which I should have cleaned up when > tightening the placeholder table cleanup years ago. > > Tests run: > 1. updated VMAnonymousClass test > 2. jcks > 3. rbt hs-nightly-runtime linux-x64 in progress > > thanks, > Karen > > From calvin.cheung at oracle.com Thu Jul 21 23:54:32 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Jul 2016 16:54:32 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> Message-ID: <579160B8.6080701@oracle.com> Based on discussions in the bug report. Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.02/ It replaces the shouldNotReachHere() with an assert. thanks, Calvin On 7/21/16, 3:00 PM, David Holmes wrote: > I'm going to wait to see what form this takes before additional > commenting beyond what is in the bug report. But a > shouldNotReachHere() implementation is/was not the intended way to > handle these conditionals. Either dummy functions are present and > called, or else no functions and the calls are guarded - not some > hybrid mix. > > Thanks, > David > > On 22/07/2016 7:05 AM, Coleen Phillimore wrote: >> >> >> On 7/21/16 4:49 PM, Calvin Cheung wrote: >>> >>> >>> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>>>> Hi Coleen, >>>>> >>>>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> I really don't like these conditionals. >>>>>> >>>>>> Why take the functions out of the #else in instanceKlass.hpp? >>>>> The idea is to catch this kind of problem during build time, not >>>>> during runtime. >>>> >>>> If you want to catch this as buildtime, then take >>>> set_cached_class_file() out of the #else part and do Chris's >>>> suggested fix (which is a smaller version of Ioi's fix). >>> If we're leaving the other functions in the #else part, I think we >>> should leave the set_cached_class_file() there as well. >>> I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. >>> What do you think? >> >> Yes, looking at this again, I think Chris's change is fine. You have to >> leave the definition of this in and cannot get a compile time error. >> >> Coleen >> >>> >>> thanks, >>> Calvin >>> >>> >>> >>>> >>>> We really don't want #ifdefs sprinkled around the vm for the minimal >>>> vm. Especially not in ClassLoaderData.cpp. >>>> >>>> Coleen >>>> >>>>> >>>>> thanks, >>>>> Calvin >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>>>> hi Calvin. >>>>>>> >>>>>>> Looks good, (r)eviewed. >>>>>>> >>>>>>> >>>>>>> cheers >>>>>>> >>>>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Summary of change: >>>>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>>>> functions. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>>>> >>>>>>>> It passed JPRT and "tier-2" testing. >>>>>>>> It also passed minimal vm build. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>> >>>> >> From david.holmes at oracle.com Fri Jul 22 01:13:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2016 11:13:57 +1000 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <579160B8.6080701@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> <579160B8.6080701@oracle.com> Message-ID: <716491ad-f50f-0557-0532-cd4811dfbabe@oracle.com> Looks good! Thanks Calvin. David On 22/07/2016 9:54 AM, Calvin Cheung wrote: > Based on discussions in the bug report. > Here's an updated webrev: > http://cr.openjdk.java.net/~ccheung/8161539/webrev.02/ > > It replaces the shouldNotReachHere() with an assert. > > thanks, > Calvin > > On 7/21/16, 3:00 PM, David Holmes wrote: >> I'm going to wait to see what form this takes before additional >> commenting beyond what is in the bug report. But a >> shouldNotReachHere() implementation is/was not the intended way to >> handle these conditionals. Either dummy functions are present and >> called, or else no functions and the calls are guarded - not some >> hybrid mix. >> >> Thanks, >> David >> >> On 22/07/2016 7:05 AM, Coleen Phillimore wrote: >>> >>> >>> On 7/21/16 4:49 PM, Calvin Cheung wrote: >>>> >>>> >>>> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>>>>> Hi Calvin, >>>>>>> >>>>>>> I really don't like these conditionals. >>>>>>> >>>>>>> Why take the functions out of the #else in instanceKlass.hpp? >>>>>> The idea is to catch this kind of problem during build time, not >>>>>> during runtime. >>>>> >>>>> If you want to catch this as buildtime, then take >>>>> set_cached_class_file() out of the #else part and do Chris's >>>>> suggested fix (which is a smaller version of Ioi's fix). >>>> If we're leaving the other functions in the #else part, I think we >>>> should leave the set_cached_class_file() there as well. >>>> I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. >>>> What do you think? >>> >>> Yes, looking at this again, I think Chris's change is fine. You have to >>> leave the definition of this in and cannot get a compile time error. >>> >>> Coleen >>> >>>> >>>> thanks, >>>> Calvin >>>> >>>> >>>> >>>>> >>>>> We really don't want #ifdefs sprinkled around the vm for the minimal >>>>> vm. Especially not in ClassLoaderData.cpp. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>>>>> hi Calvin. >>>>>>>> >>>>>>>> Looks good, (r)eviewed. >>>>>>>> >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary of change: >>>>>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>>>>> functions. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>>>>> >>>>>>>>> It passed JPRT and "tier-2" testing. >>>>>>>>> It also passed minimal vm build. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Calvin >>>>>>> >>>>> >>> From coleen.phillimore at oracle.com Fri Jul 22 01:26:34 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Jul 2016 21:26:34 -0400 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <716491ad-f50f-0557-0532-cd4811dfbabe@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> <579160B8.6080701@oracle.com> <716491ad-f50f-0557-0532-cd4811dfbabe@oracle.com> Message-ID: <1A93DBB9-0290-4860-8CC3-3EF838F72309@oracle.com> Agree. This looks good. Thanks for bearing with us! Coleen Sent from my iPhone > On Jul 21, 2016, at 9:13 PM, David Holmes wrote: > > Looks good! Thanks Calvin. > > David > >> On 22/07/2016 9:54 AM, Calvin Cheung wrote: >> Based on discussions in the bug report. >> Here's an updated webrev: >> http://cr.openjdk.java.net/~ccheung/8161539/webrev.02/ >> >> It replaces the shouldNotReachHere() with an assert. >> >> thanks, >> Calvin >> >>> On 7/21/16, 3:00 PM, David Holmes wrote: >>> I'm going to wait to see what form this takes before additional >>> commenting beyond what is in the bug report. But a >>> shouldNotReachHere() implementation is/was not the intended way to >>> handle these conditionals. Either dummy functions are present and >>> called, or else no functions and the calls are guarded - not some >>> hybrid mix. >>> >>> Thanks, >>> David >>> >>>> On 22/07/2016 7:05 AM, Coleen Phillimore wrote: >>>> >>>> >>>>> On 7/21/16 4:49 PM, Calvin Cheung wrote: >>>>> >>>>> >>>>>> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>>> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>>>>>> Hi Calvin, >>>>>>>> >>>>>>>> I really don't like these conditionals. >>>>>>>> >>>>>>>> Why take the functions out of the #else in instanceKlass.hpp? >>>>>>> The idea is to catch this kind of problem during build time, not >>>>>>> during runtime. >>>>>> >>>>>> If you want to catch this as buildtime, then take >>>>>> set_cached_class_file() out of the #else part and do Chris's >>>>>> suggested fix (which is a smaller version of Ioi's fix). >>>>> If we're leaving the other functions in the #else part, I think we >>>>> should leave the set_cached_class_file() there as well. >>>>> I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. >>>>> What do you think? >>>> >>>> Yes, looking at this again, I think Chris's change is fine. You have to >>>> leave the definition of this in and cannot get a compile time error. >>>> >>>> Coleen >>>> >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> >>>>> >>>>>> >>>>>> We really don't want #ifdefs sprinkled around the vm for the minimal >>>>>> vm. Especially not in ClassLoaderData.cpp. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>>>>>> hi Calvin. >>>>>>>>> >>>>>>>>> Looks good, (r)eviewed. >>>>>>>>> >>>>>>>>> >>>>>>>>> cheers >>>>>>>>> >>>>>>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary of change: >>>>>>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>>>>>> functions. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>>>>>> >>>>>>>>>> It passed JPRT and "tier-2" testing. >>>>>>>>>> It also passed minimal vm build. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Calvin >>>> From calvin.cheung at oracle.com Fri Jul 22 01:49:49 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Jul 2016 18:49:49 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <716491ad-f50f-0557-0532-cd4811dfbabe@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> <579160B8.6080701@oracle.com> <716491ad-f50f-0557-0532-cd4811dfbabe@oracle.com> Message-ID: <57917BBD.4040804@oracle.com> David, Thanks for your review. Calvin On 7/21/16, 6:13 PM, David Holmes wrote: > Looks good! Thanks Calvin. > > David > > On 22/07/2016 9:54 AM, Calvin Cheung wrote: >> Based on discussions in the bug report. >> Here's an updated webrev: >> http://cr.openjdk.java.net/~ccheung/8161539/webrev.02/ >> >> It replaces the shouldNotReachHere() with an assert. >> >> thanks, >> Calvin >> >> On 7/21/16, 3:00 PM, David Holmes wrote: >>> I'm going to wait to see what form this takes before additional >>> commenting beyond what is in the bug report. But a >>> shouldNotReachHere() implementation is/was not the intended way to >>> handle these conditionals. Either dummy functions are present and >>> called, or else no functions and the calls are guarded - not some >>> hybrid mix. >>> >>> Thanks, >>> David >>> >>> On 22/07/2016 7:05 AM, Coleen Phillimore wrote: >>>> >>>> >>>> On 7/21/16 4:49 PM, Calvin Cheung wrote: >>>>> >>>>> >>>>> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>>>>>> Hi Calvin, >>>>>>>> >>>>>>>> I really don't like these conditionals. >>>>>>>> >>>>>>>> Why take the functions out of the #else in instanceKlass.hpp? >>>>>>> The idea is to catch this kind of problem during build time, not >>>>>>> during runtime. >>>>>> >>>>>> If you want to catch this as buildtime, then take >>>>>> set_cached_class_file() out of the #else part and do Chris's >>>>>> suggested fix (which is a smaller version of Ioi's fix). >>>>> If we're leaving the other functions in the #else part, I think we >>>>> should leave the set_cached_class_file() there as well. >>>>> I think Chris' suggestion on using the JVMTI_ONLY macro is >>>>> sufficient. >>>>> What do you think? >>>> >>>> Yes, looking at this again, I think Chris's change is fine. You >>>> have to >>>> leave the definition of this in and cannot get a compile time error. >>>> >>>> Coleen >>>> >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> >>>>> >>>>>> >>>>>> We really don't want #ifdefs sprinkled around the vm for the minimal >>>>>> vm. Especially not in ClassLoaderData.cpp. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>>>>>> hi Calvin. >>>>>>>>> >>>>>>>>> Looks good, (r)eviewed. >>>>>>>>> >>>>>>>>> >>>>>>>>> cheers >>>>>>>>> >>>>>>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary of change: >>>>>>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>>>>>> functions. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>>>>>> >>>>>>>>>> It passed JPRT and "tier-2" testing. >>>>>>>>>> It also passed minimal vm build. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Calvin >>>>>>>> >>>>>> >>>> From calvin.cheung at oracle.com Fri Jul 22 01:51:27 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Jul 2016 18:51:27 -0700 Subject: RFR(s): 8161539: 8159666 breaks minimal VM In-Reply-To: <1A93DBB9-0290-4860-8CC3-3EF838F72309@oracle.com> References: <57911C33.3000404@oracle.com> <2A799692-8F17-4C0F-AEE6-585D70987C33@oracle.com> <57912635.4030601@oracle.com> <44d57634-0552-70a0-a4e9-36100231efa1@oracle.com> <5791356E.8070303@oracle.com> <7d5de18b-6f04-4043-d423-f2c247411d79@oracle.com> <12050410-223b-e5c8-0274-465cca31f1a9@oracle.com> <579160B8.6080701@oracle.com> <716491ad-f50f-0557-0532-cd4811dfbabe@oracle.com> <1A93DBB9-0290-4860-8CC3-3EF838F72309@oracle.com> Message-ID: <57917C1F.6070900@oracle.com> Thanks Coleen. I'll check-in the fix soon. Calvin On 7/21/16, 6:26 PM, Coleen Phillimore wrote: > Agree. This looks good. Thanks for bearing with us! > > Coleen > > Sent from my iPhone > >> On Jul 21, 2016, at 9:13 PM, David Holmes wrote: >> >> Looks good! Thanks Calvin. >> >> David >> >>> On 22/07/2016 9:54 AM, Calvin Cheung wrote: >>> Based on discussions in the bug report. >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~ccheung/8161539/webrev.02/ >>> >>> It replaces the shouldNotReachHere() with an assert. >>> >>> thanks, >>> Calvin >>> >>>> On 7/21/16, 3:00 PM, David Holmes wrote: >>>> I'm going to wait to see what form this takes before additional >>>> commenting beyond what is in the bug report. But a >>>> shouldNotReachHere() implementation is/was not the intended way to >>>> handle these conditionals. Either dummy functions are present and >>>> called, or else no functions and the calls are guarded - not some >>>> hybrid mix. >>>> >>>> Thanks, >>>> David >>>> >>>>> On 22/07/2016 7:05 AM, Coleen Phillimore wrote: >>>>> >>>>> >>>>>> On 7/21/16 4:49 PM, Calvin Cheung wrote: >>>>>> >>>>>> >>>>>>> On 7/21/16, 1:19 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> >>>>>>>> On 7/21/16 3:44 PM, Calvin Cheung wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>>> On 7/21/16, 12:32 PM, Coleen Phillimore wrote: >>>>>>>>> Hi Calvin, >>>>>>>>> >>>>>>>>> I really don't like these conditionals. >>>>>>>>> >>>>>>>>> Why take the functions out of the #else in instanceKlass.hpp? >>>>>>>> The idea is to catch this kind of problem during build time, not >>>>>>>> during runtime. >>>>>>> If you want to catch this as buildtime, then take >>>>>>> set_cached_class_file() out of the #else part and do Chris's >>>>>>> suggested fix (which is a smaller version of Ioi's fix). >>>>>> If we're leaving the other functions in the #else part, I think we >>>>>> should leave the set_cached_class_file() there as well. >>>>>> I think Chris' suggestion on using the JVMTI_ONLY macro is sufficient. >>>>>> What do you think? >>>>> Yes, looking at this again, I think Chris's change is fine. You have to >>>>> leave the definition of this in and cannot get a compile time error. >>>>> >>>>> Coleen >>>>> >>>>>> thanks, >>>>>> Calvin >>>>>> >>>>>> >>>>>> >>>>>>> We really don't want #ifdefs sprinkled around the vm for the minimal >>>>>>> vm. Especially not in ClassLoaderData.cpp. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>>>>> thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> On 7/21/16 3:23 PM, Gerard Ziemski wrote: >>>>>>>>>> hi Calvin. >>>>>>>>>> >>>>>>>>>> Looks good, (r)eviewed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> cheers >>>>>>>>>> >>>>>>>>>>> On Jul 21, 2016, at 2:02 PM, Calvin Cheung >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary of change: >>>>>>>>>>> - removes the dummy jvmti function bodies in instanceKlass.hpp; >>>>>>>>>>> - put "#if INCLUDE_JVMTI" guards at the call sites of those >>>>>>>>>>> functions. >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161539 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8161539/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> It passed JPRT and "tier-2" testing. >>>>>>>>>>> It also passed minimal vm build. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Calvin From david.holmes at oracle.com Fri Jul 22 02:36:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2016 12:36:51 +1000 Subject: RFR (S): 8161993: 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <1469106305.4338.24.camel@oracle.com> References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> <1469106305.4338.24.camel@oracle.com> Message-ID: <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> Hi Thomas, On 21/07/2016 11:05 PM, Thomas Schatzl wrote: > Hi David, > > thanks for your review. Thanks for picking up 8147910 for me. One of those little tasks I couldn't quite justify doing at the moment :) > On Thu, 2016-07-21 at 22:31 +1000, David Holmes wrote: >> Hi Thomas, >> >> On 21/07/2016 9:28 PM, Thomas Schatzl wrote: >>> >>> Hi all, >>> >>> can I have reviews for this small change that fixes crashes with >>> G1 when changing the number of available processors while running? >>> >>> The problem is that some data structures are allocated using the >>> number >>> of available processors at startup, and if you later change that >>> number >>> (i.e. increase it), g1 uses indices to access these data structures >>> beyond their capacity. >>> >>> The problem is in DirtyCardQueueSet::num_par_ids() that re-queries >>> the number of active processors, and then is used e.g. in >>> G1FromCardCache to index an array. >> To be clear num_par_ids() queries the number of configured processors >> which is constant across the life of the VM. But the number of >> parallel GC threads is determined by the number of active processors >> available to the VM - that value may be less than the number of >> configured processors. (The fact it can change over time doesn't seem >> to be a factor here - only that it may be smaller.) >> >>> >>> >>> The proposed solution is to introduce an >>> initial_active_processor_count() in the runtime that stays fixed >>> after initialization. This corresponds to the suggestion in JDK- >>> 8147910, but only fixing the immediate crash here. >> I'm not really seeing what else JDK-8147910 would want to add other >> than reporting the initial count in the error reporting, so I'd >> rather see this split into two parts - and have both issues closed >> out. All that would involve is committing the os.hpp and os.cpp and >> any change to error reporting under 8147910, and the rest under >> 8161993. A single review thread and combined push is still fine. > > Okay, can do the split of this CR into two. > > I briefly looked through the hs_err log file, but could not find any > particular section where this information would fit well. Any > suggestions? In os.cpp I would modify os::print_cpu_info as follows: void os::print_cpu_info(outputStream* st, char* buf, size_t buflen) { // cpu st->print("CPU:"); st->print("total %d", os::processor_count()); // It's not safe to query number of active processors after crash // st->print("(active %d)", os::active_processor_count()); + // but we can report the initial number of active processors + st->print(" (initial active %d)", os::initial_active_processor_count()); st->print(" %s", VM_Version::features_string()); st->cr(); pd_print_cpu_info(st, buf, buflen); } (I prefer the term "available" to "active" but the later is ingrained in the VM :( ). > >> That said I would not hide this inside os::set_processor_count the >> way you have. I can see you have done it to avoid changing all the >> os_xxx.cpp files, but the name no longer really fits as it is not a >> simple setter operation any more, and it is odd to pass in one value >> but then internally pull the other one. Albeit more work I would have >> added set_initial_active_processor_count(int initial) and >> initial_active_processor_count(), then have the OS initialization >> methods call both set_processor_count and >> set_initial_active_processor_count. Or it may be there is somewhere >> in the shared os initialization code we could add that, once, before >> it needs to be used for the worker thread calculation. I'd have to >> look at that in more detail tomorrow. > > The call could be put in the os::init_before_ergo() (or > VMVersion::init_before_ergo()) call. > > I would prefer to avoid code duplication. Agreed. init_before_ergo() seems most reasonable of the two - as this is os related. The important thing is that it happens after processor_count() is initialized (which happens earlier within os::init) and before anyone tries to query it (which I think the GC will do as part of the ergonomic setup). So an assertion in initial_active_processor_count() to ensure it is not zero would be good. And for good measure an assertion that it is zero in set_initial_active_processor_count(). >> Also if we log the initial_active_count we should log the >> _processor_count too. > > I can log both in log messages and the error log - although processor > count information is already in the log. With the new proposal I would just add the logging to set_initial_active_processor_count(). Thanks, David ----- > Thanks, > Thomas > From david.holmes at oracle.com Fri Jul 22 06:04:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2016 16:04:43 +1000 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: References: Message-ID: <8b684da0-6911-3f98-867f-5abdbf8c569a@oracle.com> Hi Karen, Generally this looks good. A couple of comments below ... On 22/07/2016 3:23 AM, Karen Kinnear wrote: > Please review: > https://bugs.openjdk.java.net/browse/JDK-8162340 > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ src/share/vm/classfile/systemDictionary.cpp 336 // leave PENDING_EXCEPTION handling in this code to ensure we do the placeholder cleanup (find_and_remove) 337 // and do not throw exceptions while holding locks Nit: can you rebalance the lines, the first is rather long. It is unclear to me what this comment means given the following code barely references PENDING_EXCEPTION - AFAICS just the end check at: 415 if (HAS_PENDING_EXCEPTION || superk_h() == NULL) { Does it really mean "Don't use CHECK_ macros to ensure we do the placeholder cleanuop ..." ? Similarly with: 642 // leave PENDING_EXCEPTION handling in this code to ensure we do the placeholder cleanup (find_and_remove) 643 // and do not throw exceptions while holding locks Though in that case we have: 722 k = SystemDictionary::handle_parallel_super_load(name, superclassname, 723 class_loader, protection_domain, lockObject, THREAD); 724 if (HAS_PENDING_EXCEPTION) { 725 return NULL; in which case we could be using CHECK_NULL anyway. Similarly: 1665 // leave PENDING_EXCEPTION handling in this code to ensure we do the placeholder cleanup (find_and_remove) 1666 // and do not throw exceptions while holding locks Again not clear what it refers to as we don't have the pattern "if (!HAS_PENDING_EXCEPTION) ..." that was removed elsewhere. And we do have some uses of check macros. --- src/share/vm/oops/instanceKlass.cpp + // ensure java/ packages only loaded by boot or platform builtin loaders Nit: the platform loader need not be a "builtin" loader - can we drop "builtin"? > http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev Is there an existing test for non-anonymous classes that claim to be in the java/ package hierarchy? Thanks, David ----- > When moving the check from resolve_from_stream to set_package, I removed > the no longer need parsed_class (!) which I should have cleaned up when > tightening the placeholder table cleanup years ago. > > Tests run: > 1. updated VMAnonymousClass test > 2. jcks > 3. rbt hs-nightly-runtime linux-x64 in progress > > thanks, > Karen > > From david.holmes at oracle.com Fri Jul 22 06:11:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2016 16:11:31 +1000 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5790C2C6.3090302@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> Message-ID: <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> Hi Alan, Looks good to me too. If Dan wants to sponsor this he is welcome to. My Friday is nearly done so it wouldn't happen till Monday (for me) at the earliest. Thanks, David On 21/07/2016 10:40 PM, Alan Burlison wrote: > On 21/07/2016 13:34, Claes Redestad wrote: > >> Hi, this sounds great, but it seems your webrev lies elsewhere. > >>> Webrev: >>> http://sthjprt.uk.oracle.com/archives/2016/07 > > Oops, sorry - cut+paste boo-boo - that's the JPRT results ;-) > > http://cr.openjdk.java.net/~alanbur/JDK-8161601 > From coleen.phillimore at oracle.com Fri Jul 22 11:07:44 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Jul 2016 07:07:44 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <8b684da0-6911-3f98-867f-5abdbf8c569a@oracle.com> References: <8b684da0-6911-3f98-867f-5abdbf8c569a@oracle.com> Message-ID: <5082601f-e1a9-4236-3d69-18a5f326af8d@oracle.com> On 7/22/16 2:04 AM, David Holmes wrote: > Hi Karen, > > Generally this looks good. A couple of comments below ... > > On 22/07/2016 3:23 AM, Karen Kinnear wrote: >> Please review: >> https://bugs.openjdk.java.net/browse/JDK-8162340 >> >> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ > > src/share/vm/classfile/systemDictionary.cpp > > 336 // leave PENDING_EXCEPTION handling in this code to ensure we do > the placeholder cleanup (find_and_remove) > 337 // and do not throw exceptions while holding locks > > Nit: can you rebalance the lines, the first is rather long. > > It is unclear to me what this comment means given the following code > barely references PENDING_EXCEPTION - AFAICS just the end check at: > > 415 if (HAS_PENDING_EXCEPTION || superk_h() == NULL) { > > Does it really mean "Don't use CHECK_ macros to ensure we do the > placeholder cleanuop ..." ? > > Similarly with: > > 642 // leave PENDING_EXCEPTION handling in this code to ensure we do > the placeholder cleanup (find_and_remove) > 643 // and do not throw exceptions while holding locks > > Though in that case we have: > > 722 k = SystemDictionary::handle_parallel_super_load(name, > superclassname, > 723 class_loader, protection_domain, lockObject, THREAD); > 724 if (HAS_PENDING_EXCEPTION) { > 725 return NULL; > > in which case we could be using CHECK_NULL anyway. > > Similarly: > > 1665 // leave PENDING_EXCEPTION handling in this code to ensure we do > the placeholder cleanup (find_and_remove) > 1666 // and do not throw exceptions while holding locks > > Again not clear what it refers to as we don't have the pattern "if > (!HAS_PENDING_EXCEPTION) ..." that was removed elsewhere. And we do > have some uses of check macros. I thought about making this comment as well, and can I suggest that these comments be moved closer to the code they are trying to describe: In resolve_super_or_fail, it should be before the call to resolve_or_null(). In resolve_instance_klass_or_null, it should be before the call to load_instance_klass(). Then they'll make sense and they won't get lost with the large comments, and the one before the function definition which isn't true. Also, it's a bit of unfortunate API that the dictionary and placeholder functions take a last THREAD parameter since it looks like you're ignoring a pending exception, but they don't throw exceptions. As a future cleanup, THREAD should be first there to eliminate this confusion. Or add Thread* thread = THREAD; at the top and use this version for these calls. As a future cleanup if you wish. Thanks, Coleen > > --- > > src/share/vm/oops/instanceKlass.cpp > > + // ensure java/ packages only loaded by boot or platform builtin > loaders > > Nit: the platform loader need not be a "builtin" loader - can we drop > "builtin"? > >> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev > > Is there an existing test for non-anonymous classes that claim to be > in the java/ package hierarchy? > > Thanks, > David > ----- > >> When moving the check from resolve_from_stream to set_package, I removed >> the no longer need parsed_class (!) which I should have cleaned up when >> tightening the placeholder table cleanup years ago. >> >> Tests run: >> 1. updated VMAnonymousClass test >> 2. jcks >> 3. rbt hs-nightly-runtime linux-x64 in progress >> >> thanks, >> Karen >> >> From thomas.schatzl at oracle.com Fri Jul 22 11:35:56 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 22 Jul 2016 13:35:56 +0200 Subject: RFR (XS): 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> <1469106305.4338.24.camel@oracle.com> <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> Message-ID: <1469187356.4267.12.camel@oracle.com> Hi David, On Fri, 2016-07-22 at 12:36 +1000, David Holmes wrote: > Hi Thomas, > > On 21/07/2016 11:05 PM, Thomas Schatzl wrote: > > > > Hi David, > > > > ? thanks for your review. > Thanks for picking up 8147910 for me. One of those little tasks I? > couldn't quite justify doing at the moment :) Np. Just want to get that unnecessary g1 crash fixed :) [...] > > > > out. All that would involve is committing the os.hpp and os.cpp > > > and any change to error reporting under 8147910, and the rest > > > under 8161993. A single review thread and combined push is still > > > fine. > > Okay, can do the split of this CR into two. > > > > I briefly looked through the hs_err log file, but could not find > > any particular section where this information would fit well. Any > > suggestions? > In os.cpp I would modify os::print_cpu_info as follows: > > void os::print_cpu_info(outputStream* st, char* buf, size_t buflen) { > ???// cpu > ???st->print("CPU:"); > ???st->print("total %d", os::processor_count()); > ???// It's not safe to query number of active processors after crash > ???// st->print("(active %d)", os::active_processor_count()); > + // but we can report the initial number of active processors > + st->print(" (initial active %d)", > os::initial_active_processor_count()); > ???st->print(" %s", VM_Version::features_string()); > ???st->cr(); > ???pd_print_cpu_info(st, buf, buflen); > } > > (I prefer the term "available" to "active" but the later is ingrained > in the VM :(??). Yeah, but let's do this renaming another time. Thanks for the suggestion. [...] > > > The call could be put in the os::init_before_ergo() (or > > VMVersion::init_before_ergo()) call. > > > > I would prefer to avoid code duplication. > Agreed. init_before_ergo() seems most reasonable of the two - as this > is ?os related. The important thing is that it happens after? > processor_count() is initialized (which happens earlier within > os::init) ?and before anyone tries to query it (which I think the GC > will do as part of the ergonomic setup). So an assertion in? > initial_active_processor_count() to ensure it is not zero would be > good. And for good measure an assertion that it is zero in? > set_initial_active_processor_count(). > > > > > > > Also if we log the initial_active_count we should log the > > > _processor_count too. > > I can log both in log messages and the error log - although > > processor > > count information is already in the log. > With the new proposal I would just add the logging to? > set_initial_active_processor_count(). New webrev: http://cr.openjdk.java.net/~tschatzl/8161993/webrev.1/?(full, it's 5 lines now, so I did not bother creating a diff webrev) Testing: Some more manual checking, jprt I will post an RFR for JDK-8147910 soon. Thanks, ? Thomas From thomas.schatzl at oracle.com Fri Jul 22 11:36:00 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 22 Jul 2016 13:36:00 +0200 Subject: RFR (S): 8147910: Cache initial active_processor_count Message-ID: <1469187360.4267.13.camel@oracle.com> Hi all, ? can I have reviews for this tiny change that adds an API to set the initial active processor count at startup? It also adds that count to the hs_err log file. It is required to fix?JDK-8161993. CR: https://bugs.openjdk.java.net/browse/JDK-8147910 Webrev: http://cr.openjdk.java.net/~tschatzl/8147910/webrev/ Testing: jprt, checking generated hs_err files using tasksel Thanks, ? Thomas From joseph.provino at oracle.com Fri Jul 22 14:40:55 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 22 Jul 2016 10:40:55 -0400 Subject: RFR (S): 8147910: Cache initial active_processor_count In-Reply-To: <1469187360.4267.13.camel@oracle.com> References: <1469187360.4267.13.camel@oracle.com> Message-ID: Tiny correction: change "to" to "from" // This value does not change dynamically. May be different to active_processor_count(). // This value does not change dynamically. May be different from active_processor_count(). looks good. joe On 7/22/2016 7:36 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this tiny change that adds an API to set the > initial active processor count at startup? It also adds that count to > the hs_err log file. > > It is required to fix JDK-8161993. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8147910 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8147910/webrev/ > > Testing: > jprt, checking generated hs_err files using tasksel > > Thanks, > Thomas > From daniel.daugherty at oracle.com Fri Jul 22 15:22:02 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 22 Jul 2016 09:22:02 -0600 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> Message-ID: I'm already setup to sponsor, but we're inside the QM window so things are being disabled and shutdown as I type... :-( Dan On 7/22/16 12:11 AM, David Holmes wrote: > Hi Alan, > > Looks good to me too. > > If Dan wants to sponsor this he is welcome to. My Friday is nearly > done so it wouldn't happen till Monday (for me) at the earliest. > > Thanks, > David > > On 21/07/2016 10:40 PM, Alan Burlison wrote: >> On 21/07/2016 13:34, Claes Redestad wrote: >> >>> Hi, this sounds great, but it seems your webrev lies elsewhere. >> >>>> Webrev: >>>> http://sthjprt.uk.oracle.com/archives/2016/07 >> >> Oops, sorry - cut+paste boo-boo - that's the JPRT results ;-) >> >> http://cr.openjdk.java.net/~alanbur/JDK-8161601 >> From coleen.phillimore at oracle.com Fri Jul 22 15:37:59 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Jul 2016 11:37:59 -0400 Subject: RFR: 8061219: Implement unit-tests for UL In-Reply-To: References: <2edd7d0d-2916-a4bb-1091-25bd1cc55512@oracle.com> <31036a63-bb39-6cf7-427d-00a42b3f1ab4@oracle.com> Message-ID: <17f307cf-f5f7-f92b-f846-1be3799d0b16@oracle.com> Hi Marcus, This looks good. Thank you for adding the comments. Coleen On 7/20/16 6:55 AM, Marcus Larsson wrote: > Hi again, > > Updated the patch with additional comments. Also fixed the copyright > header. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8061219/webrev.01/ > Incremental: > http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00-01/ > > Thanks, > Marcus > > > On 2016-07-19 10:25, Marcus Larsson wrote: >> Still looking for a *R*eviewer for this. >> >> Thanks, >> Marcus >> >> >> On 07/18/2016 10:49 AM, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to add unit tests for the unified >>> logging framework. Tests are written for the new gtest unit test >>> framework. Most of the public functions for UL should be covered, >>> but later additions have internal vm tests (in log.cpp) that will be >>> ported separately. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8061219/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8061219 >>> >>> Testing: >>> New tests through JPRT >>> >>> Thanks, >>> Marcus >> > From harold.seigel at oracle.com Fri Jul 22 16:05:43 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 22 Jul 2016 12:05:43 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <6f80496e-8b52-8a6c-5c09-719445635ee8@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <42087f8a-d808-92a5-303a-35eabf5b0843@oracle.com> <5e3cba15-6126-c526-2c43-9c07f927a5a1@oracle.com> <6f80496e-8b52-8a6c-5c09-719445635ee8@oracle.com> Message-ID: <16d03a36-3367-1be6-ceac-a0ac4fd72c3e@oracle.com> Hi Coleen, Thanks for reviewing this. I added the following two bugs, as you requested: https://bugs.openjdk.java.net/browse/JDK-8162412 https://bugs.openjdk.java.net/browse/JDK-8162401 Harold On 7/21/2016 5:40 PM, Coleen Phillimore wrote: > > > On 7/21/16 5:37 PM, Coleen Phillimore wrote: >> >> >> On 7/21/16 1:39 PM, harold seigel wrote: >>> Hi Coleen, >>> >>> Thank you for reviewing my changes! >>> >>> Please see comments inline. >>> >>> >>> On 7/20/2016 5:47 PM, Coleen Phillimore wrote: >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/src/share/vm/runtime/arguments.cpp.udiff.html >>>> >>>> >>>> To check if is_internal_module_property, the numbered ones go to >>>> is_matching_numbered_property, but do you also want to disallow: >>>> >>>> jdk.module.addreads.foo or jdk.module.addreads (with no number?) >>> We don't ignore properties like these because they do not have >>> special meaning to the jdk. I didn't want to ignore properties just >>> because they are very similar to ones that do get ignored. >> >> Don't we own the jdk.module namespace and from these patterns it's >> clear that it's an error, although we won't flag it, and somebody >> might get results that are unexpected. >> >> I think you should flag these. > > You could make this a follow-on bug. > > Coleen > >> >>>> >>>> Why aren't addmods and limitmods allowed be specified more than >>>> once on the command line and handled like the other ones? >>> Please see Alan's response. Should I open an RFE for allowing >>> multiple --add-modules options? >> >> Yes, and you can discuss it there. >> >>>> >>>> + // options. For example: use "--add-modules java.sql", not >>>> "-Djdk.module.addmods=java.sql" >>>> >>>> Does this comment need an equal sign? >>> Yes, done. >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/test/compiler/unsafe/UnsafeGetConstantField.java.udiff.html >>>> >>>> >>>> Can you fix the indentation? >>> Done. >>>> >>>> We should add an option -XX:+UseUnsafe to be a shortcut for this: >>>> >>>> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >>> Please see Alan's response. >> >> I was looking at all the tests and was wondering if there's a way for >> some other option to imply these -add-exports options, so we wouldn't >> need so many. But the patterns aren't all the same in all the tests, >> except the ALL-UNNAMED bit. >> >> I've Reviewed this now. >> >> Thanks, >> Coleen >> >> >>>> >>>> >>>> >>>> The rest looks good. This implementation looks very clean. >>> Thanks! Harold >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 7/17/16 7:05 PM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review these Hotspot VM only changes to process the seven >>>>> module-specific options that have been renamed to have gnu-like >>>>> names. JDK changes for this bug will be reviewed separately. >>>>> >>>>> Descriptions of these options are here >>>>> . For these six options, >>>>> --module-path, --upgrade-module-path, --add-modules, >>>>> --limit-modules, --add-reads, and --add-exports, the JVM just sets >>>>> a system property. For the --patch-module option, the JVM sets a >>>>> system property and then processes the option in the same way as >>>>> when it was named -Xpatch. >>>>> >>>>> Additionally, the JVM now checks properties specified on the >>>>> command line. If a property matches one of the properties used by >>>>> one of the above options then the JVM ignores the property. This >>>>> forces users to use the explicit option when wanting to do things >>>>> like add a module or a package export. >>>>> >>>>> The RFR contains two new tests. Also, many existing tests were >>>>> changed to use the new option names. >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >>>>> >>>>> The changes were tested with the JCK lang and VM tests, the JTreg >>>>> hotspot tests, and the RBT hotspot nightlies. >>>>> >>>>> Thanks, Harold >>>> >>> >> > From calvin.cheung at oracle.com Fri Jul 22 16:46:48 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 22 Jul 2016 09:46:48 -0700 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <57913A92.6040001@oracle.com> References: <578E6CBC.9010901@oracle.com> <57913A92.6040001@oracle.com> Message-ID: <57924DF8.7050707@oracle.com> Hi Lois, Just some minor comments: classLoader.cpp: 821 jio_snprintf(path, len, "%s%cmodules%c%s", home, file_sep, file_sep, module_name); I think it is better to add a #define for "modules" since it is also being used in os.cpp: 1217 char* base_classes = format_boot_path("%/modules/java.base", home, home_len, fileSep, pathSep); though I'm not sure if the #define will work with format_boot_path(). It's fine with me if you choose to fix it in a subsequent fix. nit: line too long in the following: filemap.cpp 205 assert(jrt_entry != NULL, "No modular java runtime image present when allocating the CDS classpath entry table"); classLoaderExt.hpp 73 static void add_class_path_entry(const char* path, bool check_for_duplicates, ClassPathEntry* new_entry) { thanks, Calvin On 7/21/16, 2:11 PM, Lois Foltan wrote: > > On 7/21/2016 11:25 AM, harold seigel wrote: >> Hi Lois, >> >> This is a nice fix for the exploded build system class path issues! >> >> If the callers of methods such as add_to_exploded_build_list() >> already have THREAD, can it be passed as a parameter? > Done. > >> >> In classLoader.cpp, the comment at lines 1466 - 1468 say that the >> starting classpath_index is always 1. Can you either add an assert >> for this or change line 1469 to just: classpath_index = 1; > Done. > >> >> In classLoader.hpp, could has_jimage() be renamed to something like >> has_jrt_entry so it's not confused with the has_jimage() method in >> arguments.hpp? > Done. > >> >> In filemap.cpp, can the code at lines 226 - 230 be changed to: >> >> assert(strptr + name_bytes <= strptr_max, "miscalculated buffer >> size"); >> strncpy(...) >> strptr += name_bytes; > Done. > > Thanks for the review Harold! New webrev at > http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ > Lois > >> >> Thanks, Harold >> >> >> On 7/19/2016 2:09 PM, Lois Foltan wrote: >>> Hello, >>> >>> Please review the following fix: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >>> >>> Bug: -Xbootclasspath/a breaks exploded build >>> https://bugs.openjdk.java.net/browse/JDK-8154239 >>> >>> Summary: >>> The JVM was incorrectly handling how to set up and search the >>> ClassPathEntry's for directories representing the module definitions >>> in an exploded module build situation for the boot class loader. The >>> incorrect set up and search was particularly exposed when >>> -Xbootclasspath/a was specified in conjunction with a exploded >>> module build. In an exploded module build, when >>> Modules::define_modules was called to define a module to the boot >>> loader, a ClassPathEntry was simply appended to the boot loader's >>> search list. At load class time, a class would then be searched by >>> simply traversing that list without any regards to the module that >>> class was defined in. This is incorrect behavior. The class should >>> only be searched for in the location of the module's definition that >>> it was defined within. The fix now records each module and it's >>> exploded build location in order to adhere to this rule. >>> >>> The other piece to this problem was that if -Xbootclasspath/a was >>> specified, it was incorrectly injected prior to the majority of >>> ClassPathEntry's for the exploded modules, yielding a broken and >>> incorrect search order for the boot loader. Introducing the concept >>> of a "base" or "core" piece for the boot loader which is either the >>> java runtime image or the exploded modules build and changing the >>> ClassLoader::_first_append_entry to truly be only appended entries >>> added via -Xbootclasspath/a or jvmti appended entries, introduces a >>> clean way for how this information is stored in the ClassLoader data >>> structure that maps directly to how ClassLoader::load_class() >>> searches that information. >>> >>> 215 // The boot class path consists of 3 ordered pieces: >>> 216 // 1. the module/path pairs specified to -Xpatch >>> 217 // -Xpatch:=()* >>> 218 // 2. the base piece >>> 219 // [jimage | build with exploded modules] >>> 220 // 3. boot loader append path >>> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >>> 222 // >>> 223 // The boot loader must obey this order when attempting >>> 224 // to load a class. >>> >>> >>> Testing: >>> Full hotspot nightly testing with a java runtime image build >>> JDK java/io, java/lang, java/util with both a java runtime image and >>> an exploded module build >>> JCK lang & vm with both a java runtime image and an exploded module >>> build >>> Hotspot jtreg tests with both a java runtime image and an exploded >>> module build >>> >> > From karen.kinnear at oracle.com Fri Jul 22 19:55:53 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 22 Jul 2016 15:55:53 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <578E6CBC.9010901@oracle.com> References: <578E6CBC.9010901@oracle.com> Message-ID: <50A82F1E-8E3F-425B-98FC-3F67EA2D87EF@oracle.com> Lois, This looks very cleanly done! Thank you. Couple of minor comments: 1) -Xpatch is used in a number of comments - since they are new and this overlaps with Harold?s change - not sure if you want to change to ?module-patch or choose to leave alone. Your call. 2) Could you please add a comment that the boot loader append path does not support named modules? - possibly in classLoader.hpp? 3) Could you possibly add a comment about the rule for ?module-patch? i.e. the way this is coded I believe the rule is that the patch can include a partial module, so that if you do not find a specific class in the patch entries you still look in the core entries. (Perhaps in ClassLoader.cpp under Load Attempt #1 ?) 4) did you need to write any new tests or change the expected behavior? Or were the existing tests sufficient, and needed to be run with the exploded module build? I do not need to see another web rev. thanks, Karen > On Jul 19, 2016, at 2:09 PM, Lois Foltan wrote: > > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ > > Bug: -Xbootclasspath/a breaks exploded build > https://bugs.openjdk.java.net/browse/JDK-8154239 > > Summary: > The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. > > The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. > > 215 // The boot class path consists of 3 ordered pieces: > 216 // 1. the module/path pairs specified to -Xpatch > 217 // -Xpatch:=()* > 218 // 2. the base piece > 219 // [jimage | build with exploded modules] > 220 // 3. boot loader append path > 221 // [-Xbootclasspath/a]; [jvmti appended entries] > 222 // > 223 // The boot loader must obey this order when attempting > 224 // to load a class. > > > Testing: > Full hotspot nightly testing with a java runtime image build > JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build > JCK lang & vm with both a java runtime image and an exploded module build > Hotspot jtreg tests with both a java runtime image and an exploded module build > From jiangli.zhou at oracle.com Fri Jul 22 22:45:25 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 22 Jul 2016 15:45:25 -0700 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <57913A92.6040001@oracle.com> References: <578E6CBC.9010901@oracle.com> <57913A92.6040001@oracle.com> Message-ID: <4E460683-7439-4AC9-A79A-B1229CCF351C@oracle.com> Hi Lois, This looks really good. I have one very minor comment for ClassLoader::add_to_list(). How about adding an assert to make sure _first_append_entry is also NULL under ?if (_last_append_entry == NULL)? before setting the entries? Thanks, Jiangli > On Jul 21, 2016, at 2:11 PM, Lois Foltan wrote: > > > On 7/21/2016 11:25 AM, harold seigel wrote: >> Hi Lois, >> >> This is a nice fix for the exploded build system class path issues! >> >> If the callers of methods such as add_to_exploded_build_list() already have THREAD, can it be passed as a parameter? > Done. > >> >> In classLoader.cpp, the comment at lines 1466 - 1468 say that the starting classpath_index is always 1. Can you either add an assert for this or change line 1469 to just: classpath_index = 1; > Done. > >> >> In classLoader.hpp, could has_jimage() be renamed to something like has_jrt_entry so it's not confused with the has_jimage() method in arguments.hpp? > Done. > >> >> In filemap.cpp, can the code at lines 226 - 230 be changed to: >> >> assert(strptr + name_bytes <= strptr_max, "miscalculated buffer size"); >> strncpy(...) >> strptr += name_bytes; > Done. > > Thanks for the review Harold! New webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ > Lois > >> >> Thanks, Harold >> >> >> On 7/19/2016 2:09 PM, Lois Foltan wrote: >>> Hello, >>> >>> Please review the following fix: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >>> >>> Bug: -Xbootclasspath/a breaks exploded build >>> https://bugs.openjdk.java.net/browse/JDK-8154239 >>> >>> Summary: >>> The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. >>> >>> The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. >>> >>> 215 // The boot class path consists of 3 ordered pieces: >>> 216 // 1. the module/path pairs specified to -Xpatch >>> 217 // -Xpatch:=()* >>> 218 // 2. the base piece >>> 219 // [jimage | build with exploded modules] >>> 220 // 3. boot loader append path >>> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >>> 222 // >>> 223 // The boot loader must obey this order when attempting >>> 224 // to load a class. >>> >>> >>> Testing: >>> Full hotspot nightly testing with a java runtime image build >>> JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build >>> JCK lang & vm with both a java runtime image and an exploded module build >>> Hotspot jtreg tests with both a java runtime image and an exploded module build >>> >> > From david.holmes at oracle.com Sat Jul 23 00:39:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Jul 2016 10:39:51 +1000 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> Message-ID: <15ff3ceb-aa5a-342f-a69b-9ce541052810@oracle.com> On 23/07/2016 1:22 AM, Daniel D. Daugherty wrote: > I'm already setup to sponsor, but we're inside the QM window so things are > being disabled and shutdown as I type... :-( And they won't be back on my Monday either :( I'll leave this one with you Dan. Thanks, David > Dan > > > On 7/22/16 12:11 AM, David Holmes wrote: >> Hi Alan, >> >> Looks good to me too. >> >> If Dan wants to sponsor this he is welcome to. My Friday is nearly >> done so it wouldn't happen till Monday (for me) at the earliest. >> >> Thanks, >> David >> >> On 21/07/2016 10:40 PM, Alan Burlison wrote: >>> On 21/07/2016 13:34, Claes Redestad wrote: >>> >>>> Hi, this sounds great, but it seems your webrev lies elsewhere. >>> >>>>> Webrev: >>>>> http://sthjprt.uk.oracle.com/archives/2016/07 >>> >>> Oops, sorry - cut+paste boo-boo - that's the JPRT results ;-) >>> >>> http://cr.openjdk.java.net/~alanbur/JDK-8161601 >>> > From david.holmes at oracle.com Mon Jul 25 04:55:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jul 2016 14:55:27 +1000 Subject: RFR (S): 8147910: Cache initial active_processor_count In-Reply-To: <1469187360.4267.13.camel@oracle.com> References: <1469187360.4267.13.camel@oracle.com> Message-ID: <4a200e77-668f-8ea3-dfbb-4a4cc65d88c5@oracle.com> Hi Thomas, Thanks again for taking this on. On 22/07/2016 9:36 PM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this tiny change that adds an API to set the > initial active processor count at startup? It also adds that count to > the hs_err log file. > > It is required to fix JDK-8161993. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8147910 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8147910/webrev/ src/share/vm/runtime/os.hpp Nit: can you change update_initial_active_processor_count() to initialize_initial_active_processor_count() please - otherwise it gives the impression that it can be called many times to update the value. + guarantee(_initial_active_processor_count > 0, "Initial active processor count not set yet.") An assert will suffice here. --- src/share/vm/runtime/os.cpp: ! // We access the raw value here because using the accessor will let its guarantee ! // fail if the crash occurs before initialization of this value. ! st->print(" (initial active %d)", _initial_active_processor_count); Good point! Did you find that out the hard way? :) I wonder if we should clarify the message in that case: (initial active %d - zero if not yet set) ? Thanks, David > Testing: > jprt, checking generated hs_err files using tasksel > > Thanks, > Thomas > From david.holmes at oracle.com Mon Jul 25 05:01:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jul 2016 15:01:07 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> Message-ID: <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> This all looks good. Approval is now in place. Just waiting for final conformation this builds okay for Aarch64 folk. Thanks, David On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: > Hi, > > >> I see the typo was actually much bigger than I thought :) Presumably the > Well, I edited it some more ... this time I replaced the webrev in-place, > webrev.05 is fixed now. > > I really should have an aarch64 machine :) > > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 21. Juli 2016 12:00 >> To: Lindenmaier, Goetz ; Kim Barrett >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> Copyright of register_definitions_x86.cpp is already fixed in hs-comp, >>> I'll skip it to avoid merges. >> >> This isn't going into hs-comp so I don't know when the two will collide. >> I would deal with it anyway - I can just apply the patch without >> committing, deal with any merges, and then commit as you. >> >>> I fixed the others. New webrevs, also with Coleens fixes: >>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ >> >> I see the typo was actually much bigger than I thought :) Presumably the >> INLCUDE typo caused it to be missed by a global search replace. >> >>> I also did another zero build configured as follows: >>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- >> variants=zero >>> on linuxx86_64. >> >> Thanks. >> >> David >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 21. Juli 2016 05:26 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>>>> Hi >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>> newPfmIncl/webrev.04/ >>>>> >>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >>>> CompileJvm.gmk >>>>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I >>>> documented >>>>> what I learned about the platform defines in macros.hpp. >>>> >>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) and >>>> the lingering _32 the only nit I have left is a handful of copyright >>>> updates: >>>> >>>> src/cpu/x86/vm/register_definitions_x86.cpp: >>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >>>> src/share/vm/runtime/semaphore.hpp: >>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >>>> src/cpu/ppc/vm/templateTable_ppc.hpp >>>> >>>> Then all we need is confirmation that all the open platforms that Oracle >>>> doesn't also build (aarch64 and Zero) build and run successfully after >>>> this change. >>>> >>>> I will sponsor this (in case that wasn't clear) but may have to delay it >>>> until after we sync up the hs forest with the CPU changes now in >>>> jdk9/dev. I will rebase and handle any merging if needed. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> OK, to get this through I will add >>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>> and revert this one and only place it needs to be used in the >>>>>> vmStructs_jvmci.cpp. >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such >> cleanups >>>>>> should >>>>>>> not be in this change. >>>>>> >>>>>> I did not know they had a 64-bit C1 - interesting. >>>>>> >>>>>>> >>>>>>> Thanks for doing the closed changes! >>>>>> >>>>>> You're welcome. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> that's great what you are saying and just the design I would expect! >>>>>>>>>> We did not want to have to >>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit >> ARM" >>>> so >>>>>>>>>> we worked with the Open port to ensure that shared code >> guarded >>>> by >>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>> identify >>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>>>> places >>>>>>>>>> that needed it. And sometimes we have to be careful and ensure >>>> that >>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>> >>>>>>>>> I think as a consequence the open AARCH port should define ARM, >>>> too. >>>>>>>> >>>>>>>> I would not want to do this and certainly not as part of this change. >>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, but not >>>>>>>> right now, please. >>>>>>>> >>>>>>>>> I checked the occurrences and only see three places where this >> would >>>>>> have >>>>>>>>> an effect and would have to be fixed somehow: >>>>>>>>> >>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>>>> [610] #if defined(AARCH64) && !defined(ARM) >>>>>>>>> ==> Would this break the closed port if defined? >>>>>>>> >>>>>>>> Yes - it refers to specific piece of code in the open aarch64 sources. >>>>>>>> >>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was >> used) >>>>>>>>> >>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2) >>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>> >>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>>>> [1154] #ifdef ARM >>>>>>>>> ==> Would this break the open port if defined? >>>>>>>> >>>>>>>> I don't think the open port has C1 so it would ignore the above files >>>>>>>> anyway. >>>>>>>> >>>>>>>>> All the cases below are pointless. >>>>>>>>> >>>>>>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>> conditional >>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>> I think it's quite misleading to have two defines that are 99% >>>> equivalent. >>>>>>>>> If we really need a special case here, you should define - >>>> DARM_CLOSED >>>>>>>>> or the like in your closed port. Such a name would make clear >> what's >>>> the >>>>>>>>> issue. At least, only your closed port has this problem. >>>>>>>> >>>>>>>> I really do not want to make any changes to this - ignoring the >> include >>>>>>>> macro changes everything we have is working perfectly fine just the >>>> way >>>>>>>> the defines are. So I don't want to see this change potentially break >>>>>>>> that through incidental changes. >>>>>>>> >>>>>>>> I do not see having the following is a big issue: >>>>>>>> >>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>> >>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that define >>>> intend >>>>>> it to >>>>>>>> mean. It certainly is a lot better than interpreting what the >>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the >>>>>> need to >>>>>>>> perform some of the changes as noted above. >>>>>>>> >>>>>>>> I'm preparing the review of the internal changes we need to >>>> accompany >>>>>> this. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> These should not break the open port if ARM gets defined, or can >> be >>>>>> fixed >>>>>>>> easily. >>>>>>>>> --------------------------------------------------------- >>>>>>>>> >>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>> print[1519] #elif defined(ARM) >>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>> >>>>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>> >>>>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>>>> >>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register) >>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register) >>>>>>>>> ==> Just an assertion. Will just relax the check if defined in open >>>>>> AARCH64. >>>>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>>>> [70] #if defined(ARM) || defined(AARCH64) || >>>>>>>> defined(PPC64) >>>>>>>>> ==> Fine: || >>>>>>>>> >>>>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>>>> [447] #if defined(SPARC) || defined(ARM) || >>>>>>>> defined(PPC) || defined(AARCH64) >>>>>>>>> [537] #if defined(X86) || defined(ARM) || >>>>>>>> defined(AARCH64) >>>>>>>>> ==> Fine: || >>>>>>>>> >>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>>>> defined[162] #if defined(IA32) || defined(AMD64) || >>>>>>>> defined(ARM) >>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>>>> [1358] #if defined(IA32) || defined(AMD64) || >>>>>>>> defined(ARM) >>>>>>>>> ==> Just defines a method which would be unused, should be fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> These are in code not used in the open AARCH64 port: >>>>>>>>> -------------------------------------------------- >>>>>>>>> >>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>> [215] #elif defined(ARM) >>>>>>>>> >>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>> [102] #ifdef ARM >>>>>>>>> >>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>>>> [31] #ifdef ARM >>>>>>>>> >>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>> [102] #ifdef ARM >>>>>>>>> >>>>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>>>> [31] #ifdef ARM >>>>>>>>> >>>>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>>>> [434] #ifdef ARM >>>>>>>>> >>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__, >>>> ARM, >>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>>>> >>>>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__, >>>> ARM, >>>>>>>> ARM >>>>>>>>> >>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>> store[164] #if !defined(ARM) && !defined(M68K) >>>>>>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K) >>>>>>>>> add[178] #ifdef ARM >>>>>>>>> add_ptr[190] #ifdef ARM >>>>>>>>> xchg[230] #ifdef ARM >>>>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>>>> cmpxchg[275] #ifdef ARM >>>>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>>>> >>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>> add[172] #ifdef ARM >>>>>>>>> add_ptr[184] #ifdef ARM >>>>>>>>> xchg[224] #ifdef ARM >>>>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>>>> cmpxchg[269] #ifdef ARM >>>>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>>>>>> (Parisc is gone, puh!). >>>>>>>>>>> We basically patch all the shared changes onto the sources after >>>>>>>>>>> getting them via our licensee channel. >>>>>>>>>>> I think you should fix your closed port not to re-use the names of >>>> the >>>>>>>>>>> main openJdk platforms! >>>>>>>>>> >>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to >>>> have >>>>>> to >>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit >> ARM" >>>> so >>>>>>>>>> we worked with the Open port to ensure that shared code >> guarded >>>> by >>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>> identify >>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>>>> places >>>>>>>>>> that needed it. And sometimes we have to be careful and ensure >>>> that >>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>> >>>>>>>>>> This has all been working quite nicely, as the include guards used, >> for >>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - >> which >>>>>> are >>>>>>>>>> never >>>>>>>>>> defined at the same time (derived from >>>>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>>>> But >>>>>>>>>> the >>>>>>>>>> current changes remove those unique defines and, before the >>>>>> HEADER_H >>>>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >>>>>> include >>>>>>>>>> guards, and that doesn't work as they are not mutually exclusive. >>>>>>>>>> >>>>>>>>>> So what I'm suggesting is just not getting rid of those defines, but >>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>> conditional >>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> I have no idea what hardware is addressed by your closed ports, >>>>>>>>>>> nor how you merge sources. >>>>>>>>>>> Is there also a port that sets >>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>> -DARM >>>>>>>>>>> -DARM32 >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> To fix this either you define >>>>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>>>> #define ARM64 >>>>>>>>>>> #endif >>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>>>> Then you replace all >>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>> by >>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>> by >>>>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>>>> >>>>>>>>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>>>>>>>> that you have a 32-bit port. Therefore we set up these macros >>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for >>>>>> LP64/!LP64 >>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed port >>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both >>>>>> (PPC). >>>>>>>>>>> >>>>>>>>>>> But I don't think it is necessary to do any further changes now, >>>>>> assuming >>>>>>>>>>> my change works for you as I adapted it. So we're all set I guess! >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>> >>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >>>> kind >>>>>> of >>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>> Aarch64 >>>>>>>> port >>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >> Open >>>>>> port >>>>>>>>>> use >>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>>>>>> something >>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>> >>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? >> You >>>>>> have >>>>>>>> to >>>>>>>>>>>>> check every AARCH change by RedHat against your closed >> port? >>>>>>>>>>>> >>>>>>>>>>>> The sources for the two ports are distinct so the only place we >>>> have >>>>>> to >>>>>>>>>>>> have a convention is in shared code that has CPU specific stuff >> and >>>> in >>>>>>>>>>>> the build files. >>>>>>>>>>>> >>>>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>> >>>>>>>>>>>> the closed port sets >>>>>>>>>>>> >>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>> -DARM >>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>> >>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >>>>>>>>>> Whenever >>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was >>>> referring >>>>>> to >>>>>>>>>> our >>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open >>>> Aarch64 >>>>>>>> port. >>>>>>>>>>>> >>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>>>>>> >>>>>>>>>>>> We need to keep a clear distinction. Using the combination of >>>>>> AARCH64 >>>>>>>>>>>> and ARM is not so clear. >>>>>>>>>>>> >>>>>>>>>>>> You could easily have similar issues with other port groups - eg >>>> ppc64 >>>>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up >> recently, >>>>>> and >>>>>>>>>>>>> before that it sure was equivalent. And it still is the case for >>>>>> openJDK. >>>>>>>>>>>>> >>>>>>>>>>>>> Below output is grepped out of the >> make//platform_ >>>>>> files >>>>>>>> in >>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined >>>> twice. >>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>> D_GNU_SOURCE >>>>>> - >>>>>>>>>>>> DAMD64 >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>> D_GNU_SOURCE >>>>>> - >>>>>>>>>> DIA32 >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >>>>>> DCC_INTERP >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >> DCC_INTERP - >>>>>>>> DZERO - >>>>>>>>>>>> D at ZERO_ARCHDEF@ - >> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>> DAMD64 >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >> DIA32 >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>>>>>> D at ZERO_ARCHDEF@ - >> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>> Barrett >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any >> further >>>>>>>> issues, >>>>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen >> in >>>> this >>>>>>>> new >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>>>>>> at the same time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >>>> kind >>>>>> of >>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>> Aarch64 >>>>>>>> port >>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >> Open >>>>>> port >>>>>>>>>> use >>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just >>>>>>>> something >>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >> files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should >> be >>>>>> fixed >>>>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that. >> :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value >>>> for >>>>>> the >>>>>>>>>> ifdef >>>>>>>>>>>> is >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change that >>>> value >>>>>> to >>>>>>>>>>>> match >>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to >> other >>>>>>>>>> problems >>>>>>>>>>>> as >>>>>>>>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H >> macro. >>>> In >>>>>>>>>> general >>>>>>>>>>>> you >>>>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our >>>> case >>>>>>>> ARM >>>>>>>>>>>> and >>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In >> contrast >>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen >> to >>>>>>>>>> represent >>>>>>>>>>>> the >>>>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; >>>>>> Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >> appends >>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>> CPU_HEADER_H, >>>>>>>> that >>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >>>> used >>>>>>>> only >>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do >> it >>>> to >>>>>> get >>>>>>>> is >>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >> need >>>> not >>>>>>>> be >>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >> needs >>>> to >>>>>> be >>>>>>>> an >>>>>>>>>> if- >>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>>>> in the same statement as the >> INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from >> the >>>>>> closed >>>>>>>>>> part >>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So >> we >>>> get >>>>>>>> both >>>>>>>>>>>>>> defined >>>>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >>>>>> understand >>>>>>>>>> what >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to >>>> be, >>>>>> as >>>>>>>> we >>>>>>>>>>>> are >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the current >>>>>> problem, >>>>>>>>>> but >>>>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>> ; >>>>>>>> Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>> hotspot- >>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>> ; >>>>>>>>>> Kim >>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>> hotspot- >>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>> platform >>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz >>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>>>> >> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications >> and >>>>>>>>>> comments >>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch >>>> directory, >>>>>> but >>>>>>>> I >>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. >>>>>> (Sorry I >>>>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what >> needs >>>> to >>>>>>>> be >>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this >> :).) >>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory >> that >>>> has >>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >>>>>> header >>>>>>>>>> files if >>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches >>>>>>>> internally >>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not >>>> hold: >>>>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was >> a >>>>>>>> common >>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to >> avoid >>>> this >>>>>>>> kind >>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >>>> TARGET_SO... >>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be >> moved >>>> to >>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >>>>>> elided >>>>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is >> the >>>>>>>>>> umbrella >>>>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >> appends >>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>> CPU_HEADER_H, >>>>>>>> that >>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >>>> used >>>>>>>> only >>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do >> it >>>> to >>>>>> get >>>>>>>> is >>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >> need >>>> not >>>>>>>> be >>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >> needs >>>> to >>>>>> be >>>>>>>> an >>>>>>>>>> if- >>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of >> WINDOWS? Is >>>>>> that >>>>>>>>>>>> coming >>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>>>>>> WINDOWS >>>>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is >>>> defining >>>>>> - >>>>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, >>>> but >>>>>> not >>>>>>>> in >>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >>>>>> unused >>>>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty >> file. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>> ; >>>>>>>>>> Kim >>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>> hotspot- >>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>> platform >>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz >>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's >>>> working >>>>>> on >>>>>>>> all >>>>>>>>>> the >>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the >>>>>> macros >>>>>>>> and >>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>>>>>> construction >>>>>>>>>>>> are >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >>>> macros.hpp. >>>>>> But >>>>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and >> uses >>>>>> the >>>>>>>>>> very >>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could >>>> include >>>>>>>> that >>>>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as >>>> fine >>>>>>>> with >>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is >> that >>>>>> the >>>>>>>>>> linux=1 >>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros >> should >>>> be >>>>>>>>>> upper >>>>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; >>>> hotspot- >>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >> including >>>>>>>>>> platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, >>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these >> macros >>>> are >>>>>>>> only >>>>>>>>>>>> used >>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody >>>> needs >>>>>> to >>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp >>>> and >>>>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to >>>>>> spend >>>>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted >> my >>>>>>>> current >>>>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to >> do >>>> is >>>>>>>> adding >>>>>>>>>> the >>>>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the >> includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>>>>>> proposed >>>>>>>>>> in >>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email >>>> thread >>>>>> for >>>>>>>>>> me; it >>>>>>>>>>>>>> looks >>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- >> compiler- >>>> dev >>>>>> but >>>>>>>>>> not >>>>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list >>>> this >>>>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. >> I've >>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can >>>> wait >>>>>>>> until >>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >> --- >>>> --- >>>>>> ---- >>>>>>>> --- >>>>>>>>>> ---- >>>>>>>>>>>> --- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround >> existing >>>>>>>> #defines >>>>>>>>>>>> that >>>>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so >> far: >>>>>>>> linux=1, >>>>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the >>>> leading >>>>>>>>>>>> underscore >>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>>>> >>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the >>>> values. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written >> as >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> >> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >>>>>> instead >>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) >> are >>>>>>>> defined, >>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>>>>>> underscore >>>>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >>>>>> pattern >>>>>>>>>> for >>>>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use >>>> uppercase >>>>>> for >>>>>>>>>> the >>>>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >> --- >>>> --- >>>>>> ---- >>>>>>>> --- >>>>>>>>>> ---- >>>>>>>>>>>> --- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From david.holmes at oracle.com Mon Jul 25 05:06:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jul 2016 15:06:10 +1000 Subject: RFR (XS): 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <1469187356.4267.12.camel@oracle.com> References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> <1469106305.4338.24.camel@oracle.com> <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> <1469187356.4267.12.camel@oracle.com> Message-ID: <6b4492b4-4d9f-6a1c-841c-231fab3ca282@oracle.com> On 22/07/2016 9:35 PM, Thomas Schatzl wrote: > Hi David, > > On Fri, 2016-07-22 at 12:36 +1000, David Holmes wrote: >> Hi Thomas, >> >> On 21/07/2016 11:05 PM, Thomas Schatzl wrote: >>> >>> Hi David, >>> >>> thanks for your review. >> Thanks for picking up 8147910 for me. One of those little tasks I >> couldn't quite justify doing at the moment :) > > Np. Just want to get that unnecessary g1 crash fixed :) > > [...] >> >>>> out. All that would involve is committing the os.hpp and os.cpp >>>> and any change to error reporting under 8147910, and the rest >>>> under 8161993. A single review thread and combined push is still >>>> fine. >>> Okay, can do the split of this CR into two. >>> >>> I briefly looked through the hs_err log file, but could not find >>> any particular section where this information would fit well. Any >>> suggestions? >> In os.cpp I would modify os::print_cpu_info as follows: >> >> void os::print_cpu_info(outputStream* st, char* buf, size_t buflen) { >> // cpu >> st->print("CPU:"); >> st->print("total %d", os::processor_count()); >> // It's not safe to query number of active processors after crash >> // st->print("(active %d)", os::active_processor_count()); >> + // but we can report the initial number of active processors >> + st->print(" (initial active %d)", >> os::initial_active_processor_count()); >> st->print(" %s", VM_Version::features_string()); >> st->cr(); >> pd_print_cpu_info(st, buf, buflen); >> } >> >> (I prefer the term "available" to "active" but the later is ingrained >> in the VM :( ). > > Yeah, but let's do this renaming another time. I don't expect it to ever be changed :) > Thanks for the suggestion. > > [...] >>>> The call could be put in the os::init_before_ergo() (or >>> VMVersion::init_before_ergo()) call. >>> >>> I would prefer to avoid code duplication. >> Agreed. init_before_ergo() seems most reasonable of the two - as this >> is os related. The important thing is that it happens after >> processor_count() is initialized (which happens earlier within >> os::init) and before anyone tries to query it (which I think the GC >> will do as part of the ergonomic setup). So an assertion in >> initial_active_processor_count() to ensure it is not zero would be >> good. And for good measure an assertion that it is zero in >> set_initial_active_processor_count(). >> >>>> >>>> Also if we log the initial_active_count we should log the >>>> _processor_count too. >>> I can log both in log messages and the error log - although >>> processor >>> count information is already in the log. >> With the new proposal I would just add the logging to >> set_initial_active_processor_count(). > > New webrev: > http://cr.openjdk.java.net/~tschatzl/8161993/webrev.1/ (full, it's 5 > lines now, so I did not bother creating a diff webrev) Looks good! Thanks, David > Testing: > Some more manual checking, jprt > > I will post an RFR for JDK-8147910 soon. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Mon Jul 25 08:13:12 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Jul 2016 10:13:12 +0200 Subject: RFR (S): 8147910: Cache initial active_processor_count In-Reply-To: <4a200e77-668f-8ea3-dfbb-4a4cc65d88c5@oracle.com> References: <1469187360.4267.13.camel@oracle.com> <4a200e77-668f-8ea3-dfbb-4a4cc65d88c5@oracle.com> Message-ID: <1469434392.4325.2.camel@oracle.com> Hi David, On Mon, 2016-07-25 at 14:55 +1000, David Holmes wrote: > Hi Thomas, > > Thanks again for taking this on. ? thank you for the quick reviews. > > On 22/07/2016 9:36 PM, Thomas Schatzl wrote: > > > > Hi all, > > > > ? can I have reviews for this tiny change that adds an API to set > > the > > initial active processor count at startup? It also adds that count > > to > > the hs_err log file. > > > > It is required to fix JDK-8161993. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8147910 > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8147910/webrev/ > src/share/vm/runtime/os.hpp > > Nit: can you change update_initial_active_processor_count() to? > initialize_initial_active_processor_count() please - otherwise it > gives? > the impression that it can be called many times to update the value. > > +?????guarantee(_initial_active_processor_count > 0, "Initial active? > processor count not set yet.") > > An assert will suffice here. > All fixed. > --- > > src/share/vm/runtime/os.cpp: > > !???// We access the raw value here because using the accessor will > let? > its guarantee > !???// fail if the crash occurs before initialization of this value. > !???st->print(" (initial active %d)", > _initial_active_processor_count); > > Good point! Did you find that out the hard way? :) > > I wonder if we should clarify the message in that case: > > (initial active %d - zero if not yet set) ? I think it would be just confusing in the most common case. There is always the comment in the code that already indicates that a zero value means not initilialized yet. New webrevs: http://cr.openjdk.java.net/~tschatzl/8147910/webrev.0_to_1 (diff)? http://cr.openjdk.java.net/~tschatzl/8147910/webrev.1 (full) Thanks, ? Thomas From thomas.schatzl at oracle.com Mon Jul 25 08:14:24 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Jul 2016 10:14:24 +0200 Subject: RFR (XS): 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <6b4492b4-4d9f-6a1c-841c-231fab3ca282@oracle.com> References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> <1469106305.4338.24.camel@oracle.com> <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> <1469187356.4267.12.camel@oracle.com> <6b4492b4-4d9f-6a1c-841c-231fab3ca282@oracle.com> Message-ID: <1469434464.4325.4.camel@oracle.com> Hi David, On Mon, 2016-07-25 at 15:06 +1000, David Holmes wrote: > On 22/07/2016 9:35 PM, Thomas Schatzl wrote: > > > > Hi David, > > [...] > > > > > Also if we log the initial_active_count we should log the > > > > > _processor_count too. > > > > I can log both in log messages and the error log - although > > > > processor > > > > count information is already in the log. > > > With the new proposal I would just add the logging to > > > set_initial_active_processor_count(). > > New webrev: > > http://cr.openjdk.java.net/~tschatzl/8161993/webrev.1/ (full, it's > > 5 > > lines now, so I did not bother creating a diff webrev) > Looks good! ? thanks for the review. Thanks, ? Thomas From thomas.schatzl at oracle.com Mon Jul 25 08:16:59 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Jul 2016 10:16:59 +0200 Subject: RFR (S): 8147910: Cache initial active_processor_count In-Reply-To: References: <1469187360.4267.13.camel@oracle.com> Message-ID: <1469434619.4325.7.camel@oracle.com> Hi Joe, On Fri, 2016-07-22 at 10:40 -0400, Joseph Provino wrote: > Tiny correction:??change "to" to "from" > > // This value does not change dynamically. May be different to? > active_processor_count(). // This value does not change dynamically. > May? > be different from active_processor_count(). > > looks good. ?fixed. New webrevs: http://cr.openjdk.java.net/~tschatzl/8147910/webrev.0_to_1 (diff)? http://cr.openjdk.java.net/~tschatzl/8147910/webrev.1 (full) Thanks for the review. Thomas From david.holmes at oracle.com Mon Jul 25 08:26:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jul 2016 18:26:11 +1000 Subject: RFR (S): 8147910: Cache initial active_processor_count In-Reply-To: <1469434392.4325.2.camel@oracle.com> References: <1469187360.4267.13.camel@oracle.com> <4a200e77-668f-8ea3-dfbb-4a4cc65d88c5@oracle.com> <1469434392.4325.2.camel@oracle.com> Message-ID: <3d94190f-e200-1574-e1e9-eb6e82dada83@oracle.com> Updates look good Thomas! Thanks, David On 25/07/2016 6:13 PM, Thomas Schatzl wrote: > Hi David, > > On Mon, 2016-07-25 at 14:55 +1000, David Holmes wrote: >> Hi Thomas, >> >> Thanks again for taking this on. > > thank you for the quick reviews. > >> >> On 22/07/2016 9:36 PM, Thomas Schatzl wrote: >>> >>> Hi all, >>> >>> can I have reviews for this tiny change that adds an API to set >>> the >>> initial active processor count at startup? It also adds that count >>> to >>> the hs_err log file. >>> >>> It is required to fix JDK-8161993. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8147910 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8147910/webrev/ >> src/share/vm/runtime/os.hpp >> >> Nit: can you change update_initial_active_processor_count() to >> initialize_initial_active_processor_count() please - otherwise it >> gives >> the impression that it can be called many times to update the value. >> >> + guarantee(_initial_active_processor_count > 0, "Initial active >> processor count not set yet.") >> >> An assert will suffice here. >> > > All fixed. > >> --- >> >> src/share/vm/runtime/os.cpp: >> >> ! // We access the raw value here because using the accessor will >> let >> its guarantee >> ! // fail if the crash occurs before initialization of this value. >> ! st->print(" (initial active %d)", >> _initial_active_processor_count); >> >> Good point! Did you find that out the hard way? :) >> >> I wonder if we should clarify the message in that case: >> >> (initial active %d - zero if not yet set) > > I think it would be just confusing in the most common case. There is > always the comment in the code that already indicates that a zero value > means not initilialized yet. > > New webrevs: > http://cr.openjdk.java.net/~tschatzl/8147910/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8147910/webrev.1 (full) > > > Thanks, > Thomas > From thomas.schatzl at oracle.com Mon Jul 25 08:33:33 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Jul 2016 10:33:33 +0200 Subject: RFR (S): 8147910: Cache initial active_processor_count In-Reply-To: <3d94190f-e200-1574-e1e9-eb6e82dada83@oracle.com> References: <1469187360.4267.13.camel@oracle.com> <4a200e77-668f-8ea3-dfbb-4a4cc65d88c5@oracle.com> <1469434392.4325.2.camel@oracle.com> <3d94190f-e200-1574-e1e9-eb6e82dada83@oracle.com> Message-ID: <1469435613.4325.12.camel@oracle.com> Hi David, On Mon, 2016-07-25 at 18:26 +1000, David Holmes wrote: > Updates look good Thomas! ? that was fast. Thanks a lot! Thomas From Alan.Burlison at oracle.com Mon Jul 25 08:42:08 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 25 Jul 2016 09:42:08 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> Message-ID: <5795D0E0.1080401@oracle.com> On 22/07/2016 16:22, Daniel D. Daugherty wrote: > I'm already setup to sponsor, but we're inside the QM window so things are > being disabled and shutdown as I type... :-( I'm guessing that's some sort of "gate closed" period? -- Alan Burlison -- From shafi.s.ahmad at oracle.com Mon Jul 25 11:53:59 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 25 Jul 2016 04:53:59 -0700 (PDT) Subject: [8u] RFR JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) Message-ID: <4971842d-29db-4116-ac50-e506dcc14dc7@default> Hi, Please review the small code change for bug: "JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*)" on jdk8u-dev Summary: Method::deallocate_contents() should clear 'this' from list of Methods in JNIMethodBlock, similarly to clear_all_methods() does it, when class is unloaded. After this change I am seeing Method::is_method_id() is getting called with NULL and I have done below change to avoid crash - assert(m != NULL, "should be called with non-null method"); + if (m == NULL) { + return false; + } Webrev: http://cr.openjdk.java.net/~shshahma/8161144/webrev/ Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8161144 Test: Run jprt Regards, Shafi From coleen.phillimore at oracle.com Mon Jul 25 12:21:36 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 25 Jul 2016 08:21:36 -0400 Subject: [8u] RFR JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) In-Reply-To: <4971842d-29db-4116-ac50-e506dcc14dc7@default> References: <4971842d-29db-4116-ac50-e506dcc14dc7@default> Message-ID: <1b64e628-c40a-dcd4-e41f-34b96d5a64b1@oracle.com> This looks good. Was this a backport or is it still broken in 9? thanks, Coleen On 7/25/16 7:53 AM, Shafi Ahmad wrote: > Hi, > > Please review the small code change for bug: "JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*)" on jdk8u-dev > > Summary: > Method::deallocate_contents() should clear 'this' from list of Methods in JNIMethodBlock, similarly to clear_all_methods() does it, when class is unloaded. > After this change I am seeing Method::is_method_id() is getting called with NULL and I have done below change to avoid crash > > - assert(m != NULL, "should be called with non-null method"); > + if (m == NULL) { > + return false; > + } > > Webrev: http://cr.openjdk.java.net/~shshahma/8161144/webrev/ > Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8161144 > > Test: Run jprt > > Regards, > Shafi From lois.foltan at oracle.com Mon Jul 25 16:18:36 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 25 Jul 2016 12:18:36 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <50A82F1E-8E3F-425B-98FC-3F67EA2D87EF@oracle.com> References: <578E6CBC.9010901@oracle.com> <50A82F1E-8E3F-425B-98FC-3F67EA2D87EF@oracle.com> Message-ID: <57963BDC.6000500@oracle.com> On 7/22/2016 3:55 PM, Karen Kinnear wrote: > Lois, > > This looks very cleanly done! Thank you. Thank you for the review Karen! > > Couple of minor comments: > 1) -Xpatch is used in a number of comments - since they are new and this overlaps with Harold?s change - not sure > if you want to change to ?module-patch or choose to leave alone. Your call. Yes, that will be a merge issue if this change bubbles up from the hs repo and Harold's comes in via the jake repo into jdk9/dev. We will monitor this and make the appropriate changes. > > 2) Could you please add a comment that the boot loader append path does not support named modules? > - possibly in classLoader.hpp? Done. > > 3) Could you possibly add a comment about the rule for ?module-patch? i.e. the way this is coded > I believe the rule is that the patch can include a partial module, so that if you do not find a specific > class in the patch entries you still look in the core entries. (Perhaps in ClassLoader.cpp under Load Attempt #1 ?) Done. > > 4) did you need to write any new tests or change the expected behavior? Or were the existing tests sufficient, and needed > to be run with the exploded module build? There was ample tests in our existing test systems that appeared as test failures when running with the exploded module build. I ran most tests twice, once with a java runtime image and again with an exploded module build. Thanks, Lois > > I do not need to see another web rev. > > thanks, > Karen > > >> On Jul 19, 2016, at 2:09 PM, Lois Foltan wrote: >> >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >> >> Bug: -Xbootclasspath/a breaks exploded build >> https://bugs.openjdk.java.net/browse/JDK-8154239 >> >> Summary: >> The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. >> >> The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. >> >> 215 // The boot class path consists of 3 ordered pieces: >> 216 // 1. the module/path pairs specified to -Xpatch >> 217 // -Xpatch:=()* >> 218 // 2. the base piece >> 219 // [jimage | build with exploded modules] >> 220 // 3. boot loader append path >> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >> 222 // >> 223 // The boot loader must obey this order when attempting >> 224 // to load a class. >> >> >> Testing: >> Full hotspot nightly testing with a java runtime image build >> JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build >> JCK lang & vm with both a java runtime image and an exploded module build >> Hotspot jtreg tests with both a java runtime image and an exploded module build >> From lois.foltan at oracle.com Mon Jul 25 17:32:03 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 25 Jul 2016 13:32:03 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <57924DF8.7050707@oracle.com> References: <578E6CBC.9010901@oracle.com> <57913A92.6040001@oracle.com> <57924DF8.7050707@oracle.com> Message-ID: <57964D13.40400@oracle.com> On 7/22/2016 12:46 PM, Calvin Cheung wrote: > Hi Lois, > > Just some minor comments: > > classLoader.cpp: > 821 jio_snprintf(path, len, "%s%cmodules%c%s", home, file_sep, > file_sep, module_name); > > I think it is better to add a #define for "modules" since it is also > being used in os.cpp: > 1217 char* base_classes = format_boot_path("%/modules/java.base", > home, home_len, fileSep, pathSep); > though I'm not sure if the #define will work with format_boot_path(). Hi Calvin, I did look at this, but at this point would prefer a subsequent fix. > > It's fine with me if you choose to fix it in a subsequent fix. > > nit: line too long in the following: > > filemap.cpp > > 205 assert(jrt_entry != NULL, "No modular java runtime image > present when allocating the CDS classpath entry table"); Done. > > classLoaderExt.hpp > > 73 static void add_class_path_entry(const char* path, bool > check_for_duplicates, ClassPathEntry* new_entry) { Done. Thanks for the review! Lois > > thanks, > Calvin > > On 7/21/16, 2:11 PM, Lois Foltan wrote: >> >> On 7/21/2016 11:25 AM, harold seigel wrote: >>> Hi Lois, >>> >>> This is a nice fix for the exploded build system class path issues! >>> >>> If the callers of methods such as add_to_exploded_build_list() >>> already have THREAD, can it be passed as a parameter? >> Done. >> >>> >>> In classLoader.cpp, the comment at lines 1466 - 1468 say that the >>> starting classpath_index is always 1. Can you either add an assert >>> for this or change line 1469 to just: classpath_index = 1; >> Done. >> >>> >>> In classLoader.hpp, could has_jimage() be renamed to something like >>> has_jrt_entry so it's not confused with the has_jimage() method in >>> arguments.hpp? >> Done. >> >>> >>> In filemap.cpp, can the code at lines 226 - 230 be changed to: >>> >>> assert(strptr + name_bytes <= strptr_max, "miscalculated buffer >>> size"); >>> strncpy(...) >>> strptr += name_bytes; >> Done. >> >> Thanks for the review Harold! New webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ >> Lois >> >>> >>> Thanks, Harold >>> >>> >>> On 7/19/2016 2:09 PM, Lois Foltan wrote: >>>> Hello, >>>> >>>> Please review the following fix: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >>>> >>>> Bug: -Xbootclasspath/a breaks exploded build >>>> https://bugs.openjdk.java.net/browse/JDK-8154239 >>>> >>>> Summary: >>>> The JVM was incorrectly handling how to set up and search the >>>> ClassPathEntry's for directories representing the module >>>> definitions in an exploded module build situation for the boot >>>> class loader. The incorrect set up and search was particularly >>>> exposed when -Xbootclasspath/a was specified in conjunction with a >>>> exploded module build. In an exploded module build, when >>>> Modules::define_modules was called to define a module to the boot >>>> loader, a ClassPathEntry was simply appended to the boot loader's >>>> search list. At load class time, a class would then be searched by >>>> simply traversing that list without any regards to the module that >>>> class was defined in. This is incorrect behavior. The class >>>> should only be searched for in the location of the module's >>>> definition that it was defined within. The fix now records each >>>> module and it's exploded build location in order to adhere to this >>>> rule. >>>> >>>> The other piece to this problem was that if -Xbootclasspath/a was >>>> specified, it was incorrectly injected prior to the majority of >>>> ClassPathEntry's for the exploded modules, yielding a broken and >>>> incorrect search order for the boot loader. Introducing the >>>> concept of a "base" or "core" piece for the boot loader which is >>>> either the java runtime image or the exploded modules build and >>>> changing the ClassLoader::_first_append_entry to truly be only >>>> appended entries added via -Xbootclasspath/a or jvmti appended >>>> entries, introduces a clean way for how this information is stored >>>> in the ClassLoader data structure that maps directly to how >>>> ClassLoader::load_class() searches that information. >>>> >>>> 215 // The boot class path consists of 3 ordered pieces: >>>> 216 // 1. the module/path pairs specified to -Xpatch >>>> 217 // -Xpatch:=()* >>>> 218 // 2. the base piece >>>> 219 // [jimage | build with exploded modules] >>>> 220 // 3. boot loader append path >>>> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >>>> 222 // >>>> 223 // The boot loader must obey this order when attempting >>>> 224 // to load a class. >>>> >>>> >>>> Testing: >>>> Full hotspot nightly testing with a java runtime image build >>>> JDK java/io, java/lang, java/util with both a java runtime image >>>> and an exploded module build >>>> JCK lang & vm with both a java runtime image and an exploded module >>>> build >>>> Hotspot jtreg tests with both a java runtime image and an exploded >>>> module build >>>> >>> >> From lois.foltan at oracle.com Mon Jul 25 18:38:17 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 25 Jul 2016 14:38:17 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <4E460683-7439-4AC9-A79A-B1229CCF351C@oracle.com> References: <578E6CBC.9010901@oracle.com> <57913A92.6040001@oracle.com> <4E460683-7439-4AC9-A79A-B1229CCF351C@oracle.com> Message-ID: <57965C99.5020200@oracle.com> On 7/22/2016 6:45 PM, Jiangli Zhou wrote: > Hi Lois, > > This looks really good. I have one very minor comment for ClassLoader::add_to_list(). How about adding an assert to make sure _first_append_entry is also NULL under ?if (_last_append_entry == NULL)? before setting the entries? Done. Thanks for the review Jiangli! For completeness, here is a webrev that incorporates all review comments: http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.2/webrev/ Lois > > Thanks, > Jiangli > > >> On Jul 21, 2016, at 2:11 PM, Lois Foltan wrote: >> >> >> On 7/21/2016 11:25 AM, harold seigel wrote: >>> Hi Lois, >>> >>> This is a nice fix for the exploded build system class path issues! >>> >>> If the callers of methods such as add_to_exploded_build_list() already have THREAD, can it be passed as a parameter? >> Done. >> >>> In classLoader.cpp, the comment at lines 1466 - 1468 say that the starting classpath_index is always 1. Can you either add an assert for this or change line 1469 to just: classpath_index = 1; >> Done. >> >>> In classLoader.hpp, could has_jimage() be renamed to something like has_jrt_entry so it's not confused with the has_jimage() method in arguments.hpp? >> Done. >> >>> In filemap.cpp, can the code at lines 226 - 230 be changed to: >>> >>> assert(strptr + name_bytes <= strptr_max, "miscalculated buffer size"); >>> strncpy(...) >>> strptr += name_bytes; >> Done. >> >> Thanks for the review Harold! New webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ >> Lois >> >>> Thanks, Harold >>> >>> >>> On 7/19/2016 2:09 PM, Lois Foltan wrote: >>>> Hello, >>>> >>>> Please review the following fix: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >>>> >>>> Bug: -Xbootclasspath/a breaks exploded build >>>> https://bugs.openjdk.java.net/browse/JDK-8154239 >>>> >>>> Summary: >>>> The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. >>>> >>>> The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. >>>> >>>> 215 // The boot class path consists of 3 ordered pieces: >>>> 216 // 1. the module/path pairs specified to -Xpatch >>>> 217 // -Xpatch:=()* >>>> 218 // 2. the base piece >>>> 219 // [jimage | build with exploded modules] >>>> 220 // 3. boot loader append path >>>> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >>>> 222 // >>>> 223 // The boot loader must obey this order when attempting >>>> 224 // to load a class. >>>> >>>> >>>> Testing: >>>> Full hotspot nightly testing with a java runtime image build >>>> JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build >>>> JCK lang & vm with both a java runtime image and an exploded module build >>>> Hotspot jtreg tests with both a java runtime image and an exploded module build >>>> From daniel.daugherty at oracle.com Mon Jul 25 20:20:56 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 25 Jul 2016 14:20:56 -0600 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5795D0E0.1080401@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> <5795D0E0.1080401@oracle.com> Message-ID: On 7/25/16 2:42 AM, Alan Burlison wrote: > On 22/07/2016 16:22, Daniel D. Daugherty wrote: > >> I'm already setup to sponsor, but we're inside the QM window so >> things are >> being disabled and shutdown as I type... :-( > > I'm guessing that's some sort of "gate closed" period? > Oracle's reqular Quarterly Maintenance (QM) was this past weekend. The systems (JPRT, testing, etc) needed for pushing changes into the repos were down for maintenance. So the "gates" were probably open, but HotSpot forest protocol is that all changes must go through systems that were down... Dan From jiangli.zhou at oracle.com Mon Jul 25 21:01:46 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 25 Jul 2016 14:01:46 -0700 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <57965C99.5020200@oracle.com> References: <578E6CBC.9010901@oracle.com> <57913A92.6040001@oracle.com> <4E460683-7439-4AC9-A79A-B1229CCF351C@oracle.com> <57965C99.5020200@oracle.com> Message-ID: <6F26E4C1-15D5-4F46-BCF7-6161D5A510F2@oracle.com> Hi Lois, > On Jul 25, 2016, at 11:38 AM, Lois Foltan wrote: > > > On 7/22/2016 6:45 PM, Jiangli Zhou wrote: >> Hi Lois, >> >> This looks really good. I have one very minor comment for ClassLoader::add_to_list(). How about adding an assert to make sure _first_append_entry is also NULL under ?if (_last_append_entry == NULL)? before setting the entries? > Done. > > Thanks for the review Jiangli! For completeness, here is a webrev that incorporates all review comments: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.2/webrev/ Looks good. Thank you for adding the exploded module build checks in FileMapHeader::validate() and Arguments::check_unsupported_dumping_properties(). Thanks, Jiangli > > Lois > >> >> Thanks, >> Jiangli >> >> >>> On Jul 21, 2016, at 2:11 PM, Lois Foltan wrote: >>> >>> >>> On 7/21/2016 11:25 AM, harold seigel wrote: >>>> Hi Lois, >>>> >>>> This is a nice fix for the exploded build system class path issues! >>>> >>>> If the callers of methods such as add_to_exploded_build_list() already have THREAD, can it be passed as a parameter? >>> Done. >>> >>>> In classLoader.cpp, the comment at lines 1466 - 1468 say that the starting classpath_index is always 1. Can you either add an assert for this or change line 1469 to just: classpath_index = 1; >>> Done. >>> >>>> In classLoader.hpp, could has_jimage() be renamed to something like has_jrt_entry so it's not confused with the has_jimage() method in arguments.hpp? >>> Done. >>> >>>> In filemap.cpp, can the code at lines 226 - 230 be changed to: >>>> >>>> assert(strptr + name_bytes <= strptr_max, "miscalculated buffer size"); >>>> strncpy(...) >>>> strptr += name_bytes; >>> Done. >>> >>> Thanks for the review Harold! New webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ >>> Lois >>> >>>> Thanks, Harold >>>> >>>> >>>> On 7/19/2016 2:09 PM, Lois Foltan wrote: >>>>> Hello, >>>>> >>>>> Please review the following fix: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >>>>> >>>>> Bug: -Xbootclasspath/a breaks exploded build >>>>> https://bugs.openjdk.java.net/browse/JDK-8154239 >>>>> >>>>> Summary: >>>>> The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. >>>>> >>>>> The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. >>>>> >>>>> 215 // The boot class path consists of 3 ordered pieces: >>>>> 216 // 1. the module/path pairs specified to -Xpatch >>>>> 217 // -Xpatch:=()* >>>>> 218 // 2. the base piece >>>>> 219 // [jimage | build with exploded modules] >>>>> 220 // 3. boot loader append path >>>>> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >>>>> 222 // >>>>> 223 // The boot loader must obey this order when attempting >>>>> 224 // to load a class. >>>>> >>>>> >>>>> Testing: >>>>> Full hotspot nightly testing with a java runtime image build >>>>> JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build >>>>> JCK lang & vm with both a java runtime image and an exploded module build >>>>> Hotspot jtreg tests with both a java runtime image and an exploded module build >>>>> > > From Alan.Burlison at oracle.com Mon Jul 25 21:49:26 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 25 Jul 2016 22:49:26 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> <5795D0E0.1080401@oracle.com> Message-ID: On 25/07/16 21:20, Daniel D. Daugherty wrote: > Oracle's reqular Quarterly Maintenance (QM) was this past weekend. > The systems (JPRT, testing, etc) needed for pushing changes into > the repos were down for maintenance. > > So the "gates" were probably open, but HotSpot forest protocol is > that all changes must go through systems that were down... Ah, OK - thanks for the explanation. -- Alan Burlison -- From jiangli.zhou at Oracle.COM Mon Jul 25 23:04:53 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Mon, 25 Jul 2016 16:04:53 -0700 Subject: RFR: JDK-8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134 Message-ID: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> Please review the following webrev for JDK-8156959 fix. http://cr.openjdk.java.net/~jiangli/8156959/webrev.00/ The SensorInfo::has_pending_requests() is not thread safe. It tests '_pending_trigger_count > 0 || _pending_clear_count > 0?. In rare cases, there is a race condition in which the check done by the service thread might return ?false? incorrectly while _pending_trigger_count is incremented to 1 and _pending_clear_count is reset to 0 by other thread. In that case, the 'assert(has_pending_requests(), "Must have pending request?)? in SensorInfo::process_pending_requests() becomes invalid. The fix removes the invalid assert. As _pending_trigger_count can only be decremented by the service thread and all other threads can only increment the _pending_trigger_count, the race condition issue of SensorInfo::has_pending_requests() is harmless in other usages. If the service thread fails to catch the pending request (when has_pending_requests() returns false incorrectly), it can catch the it in the next iteration. Please see the JDK-8156959 for detailed analysis. Test: JPRT and RBT hotspot_all. Thanks, Jiangli From david.holmes at oracle.com Tue Jul 26 01:12:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Jul 2016 11:12:55 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> Message-ID: On 25/07/2016 3:01 PM, David Holmes wrote: > This all looks good. Approval is now in place. Just waiting for final > conformation this builds okay for Aarch64 folk. That confirmation was sent to compiler-dev so the changes have been pushed. David > Thanks, > David > > On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> >>> I see the typo was actually much bigger than I thought :) Presumably the >> Well, I edited it some more ... this time I replaced the webrev in-place, >> webrev.05 is fixed now. >> >> I really should have an aarch64 machine :) >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 21. Juli 2016 12:00 >>> To: Lindenmaier, Goetz ; Kim Barrett >>> >>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>> >>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> Copyright of register_definitions_x86.cpp is already fixed in hs-comp, >>>> I'll skip it to avoid merges. >>> >>> This isn't going into hs-comp so I don't know when the two will collide. >>> I would deal with it anyway - I can just apply the patch without >>> committing, deal with any merges, and then commit as you. >>> >>>> I fixed the others. New webrevs, also with Coleens fixes: >>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ >>> >>> I see the typo was actually much bigger than I thought :) Presumably the >>> INLCUDE typo caused it to be missed by a global search replace. >>> >>>> I also did another zero build configured as follows: >>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- >>> variants=zero >>>> on linuxx86_64. >>> >>> Thanks. >>> >>> David >>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Donnerstag, 21. Juli 2016 05:26 >>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>> >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>> >>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>>>>> Hi >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>> newPfmIncl/webrev.04/ >>>>>> >>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >>>>> CompileJvm.gmk >>>>>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I >>>>> documented >>>>>> what I learned about the platform defines in macros.hpp. >>>>> >>>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) >>>>> and >>>>> the lingering _32 the only nit I have left is a handful of copyright >>>>> updates: >>>>> >>>>> src/cpu/x86/vm/register_definitions_x86.cpp: >>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >>>>> src/share/vm/runtime/semaphore.hpp: >>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >>>>> src/cpu/ppc/vm/templateTable_ppc.hpp >>>>> >>>>> Then all we need is confirmation that all the open platforms that >>>>> Oracle >>>>> doesn't also build (aarch64 and Zero) build and run successfully after >>>>> this change. >>>>> >>>>> I will sponsor this (in case that wasn't clear) but may have to >>>>> delay it >>>>> until after we sync up the hs forest with the CPU changes now in >>>>> jdk9/dev. I will rebase and handle any merging if needed. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>> >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>> >>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> OK, to get this through I will add >>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>> and revert this one and only place it needs to be used in the >>>>>>> vmStructs_jvmci.cpp. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such >>> cleanups >>>>>>> should >>>>>>>> not be in this change. >>>>>>> >>>>>>> I did not know they had a 64-bit C1 - interesting. >>>>>>> >>>>>>>> >>>>>>>> Thanks for doing the closed changes! >>>>>>> >>>>>>> You're welcome. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>> >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> that's great what you are saying and just the design I would >>>>>>>>>> expect! >>>>>>>>>>> We did not want to have to >>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit >>> ARM" >>>>> so >>>>>>>>>>> we worked with the Open port to ensure that shared code >>> guarded >>>>> by >>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>> identify >>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>>>>> places >>>>>>>>>>> that needed it. And sometimes we have to be careful and ensure >>>>> that >>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>> >>>>>>>>>> I think as a consequence the open AARCH port should define ARM, >>>>> too. >>>>>>>>> >>>>>>>>> I would not want to do this and certainly not as part of this >>>>>>>>> change. >>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, >>>>>>>>> but not >>>>>>>>> right now, please. >>>>>>>>> >>>>>>>>>> I checked the occurrences and only see three places where this >>> would >>>>>>> have >>>>>>>>>> an effect and would have to be fixed somehow: >>>>>>>>>> >>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>>>>> [610] #if defined(AARCH64) && >>>>>>>>>> !defined(ARM) >>>>>>>>>> ==> Would this break the closed port if defined? >>>>>>>>> >>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 >>>>>>>>> sources. >>>>>>>>> >>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was >>> used) >>>>>>>>>> >>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>>>>> load_item_force[253] #if !defined(ARM) && >>>>>>>>>> !defined(E500V2) >>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>> >>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>>>>> [1154] #ifdef ARM >>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>> >>>>>>>>> I don't think the open port has C1 so it would ignore the above >>>>>>>>> files >>>>>>>>> anyway. >>>>>>>>> >>>>>>>>>> All the cases below are pointless. >>>>>>>>>> >>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>> defines, but >>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>> conditional >>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>> I think it's quite misleading to have two defines that are 99% >>>>> equivalent. >>>>>>>>>> If we really need a special case here, you should define - >>>>> DARM_CLOSED >>>>>>>>>> or the like in your closed port. Such a name would make clear >>> what's >>>>> the >>>>>>>>>> issue. At least, only your closed port has this problem. >>>>>>>>> >>>>>>>>> I really do not want to make any changes to this - ignoring the >>> include >>>>>>>>> macro changes everything we have is working perfectly fine just >>>>>>>>> the >>>>> way >>>>>>>>> the defines are. So I don't want to see this change potentially >>>>>>>>> break >>>>>>>>> that through incidental changes. >>>>>>>>> >>>>>>>>> I do not see having the following is a big issue: >>>>>>>>> >>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>> >>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that define >>>>> intend >>>>>>> it to >>>>>>>>> mean. It certainly is a lot better than interpreting what the >>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the >>>>>>> need to >>>>>>>>> perform some of the changes as noted above. >>>>>>>>> >>>>>>>>> I'm preparing the review of the internal changes we need to >>>>> accompany >>>>>>> this. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> These should not break the open port if ARM gets defined, or can >>> be >>>>>>> fixed >>>>>>>>> easily. >>>>>>>>>> --------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>> print[1519] #elif defined(ARM) >>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>> >>>>>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>> >>>>>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>>>>> >>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == >>>>>>>>>> cpu_register) >>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == >>>>>>>>>> cpu_register) >>>>>>>>>> ==> Just an assertion. Will just relax the check if defined >>>>>>>>>> in open >>>>>>> AARCH64. >>>>>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>>>>> [70] #if defined(ARM) || >>>>>>>>>> defined(AARCH64) || >>>>>>>>> defined(PPC64) >>>>>>>>>> ==> Fine: || >>>>>>>>>> >>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>>>>> [447] #if defined(SPARC) || >>>>>>>>>> defined(ARM) || >>>>>>>>> defined(PPC) || defined(AARCH64) >>>>>>>>>> [537] #if defined(X86) || >>>>>>>>>> defined(ARM) || >>>>>>>>> defined(AARCH64) >>>>>>>>>> ==> Fine: || >>>>>>>>>> >>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>>>>> defined[162] #if defined(IA32) || >>>>>>>>>> defined(AMD64) || >>>>>>>>> defined(ARM) >>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>>>>> [1358] #if defined(IA32) || >>>>>>>>>> defined(AMD64) || >>>>>>>>> defined(ARM) >>>>>>>>>> ==> Just defines a method which would be unused, should be fine. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> These are in code not used in the open AARCH64 port: >>>>>>>>>> -------------------------------------------------- >>>>>>>>>> >>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>> [215] #elif defined(ARM) >>>>>>>>>> >>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>> [102] #ifdef ARM >>>>>>>>>> >>>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>>>>> [31] #ifdef ARM >>>>>>>>>> >>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>> [102] #ifdef ARM >>>>>>>>>> >>>>>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>>>>> [31] #ifdef ARM >>>>>>>>>> >>>>>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>>>>> [434] #ifdef ARM >>>>>>>>>> >>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, >>>>>>>>>> __powerpc__, >>>>> ARM, >>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>>>>> >>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, >>>>>>>>>> __powerpc__, >>>>> ARM, >>>>>>>>> ARM >>>>>>>>>> >>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>> store[164] #if !defined(ARM) && >>>>>>>>>> !defined(M68K) >>>>>>>>>> store_ptr[171] #if !defined(ARM) && >>>>>>>>>> !defined(M68K) >>>>>>>>>> add[178] #ifdef ARM >>>>>>>>>> add_ptr[190] #ifdef ARM >>>>>>>>>> xchg[230] #ifdef ARM >>>>>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>>>>> cmpxchg[275] #ifdef ARM >>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>>>>> >>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>> add[172] #ifdef ARM >>>>>>>>>> add_ptr[184] #ifdef ARM >>>>>>>>>> xchg[224] #ifdef ARM >>>>>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>>>>> cmpxchg[269] #ifdef ARM >>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>> Barrett >>>>>>>>>>> >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>>>>>>> (Parisc is gone, puh!). >>>>>>>>>>>> We basically patch all the shared changes onto the sources >>>>>>>>>>>> after >>>>>>>>>>>> getting them via our licensee channel. >>>>>>>>>>>> I think you should fix your closed port not to re-use the >>>>>>>>>>>> names of >>>>> the >>>>>>>>>>>> main openJdk platforms! >>>>>>>>>>> >>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to >>>>> have >>>>>>> to >>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit >>> ARM" >>>>> so >>>>>>>>>>> we worked with the Open port to ensure that shared code >>> guarded >>>>> by >>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>> identify >>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>>>>> places >>>>>>>>>>> that needed it. And sometimes we have to be careful and ensure >>>>> that >>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>> >>>>>>>>>>> This has all been working quite nicely, as the include guards >>>>>>>>>>> used, >>> for >>>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - >>> which >>>>>>> are >>>>>>>>>>> never >>>>>>>>>>> defined at the same time (derived from >>>>>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>>>>> But >>>>>>>>>>> the >>>>>>>>>>> current changes remove those unique defines and, before the >>>>>>> HEADER_H >>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >>>>>>> include >>>>>>>>>>> guards, and that doesn't work as they are not mutually >>>>>>>>>>> exclusive. >>>>>>>>>>> >>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>> defines, but >>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>> conditional >>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> I have no idea what hardware is addressed by your closed ports, >>>>>>>>>>>> nor how you merge sources. >>>>>>>>>>>> Is there also a port that sets >>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>> -DARM >>>>>>>>>>>> -DARM32 >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> To fix this either you define >>>>>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>>>>> #define ARM64 >>>>>>>>>>>> #endif >>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>>>>> Then you replace all >>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>> by >>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>> by >>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>>>>> >>>>>>>>>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these macros >>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for >>>>>>> LP64/!LP64 >>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed >>>>>>>>>>>> port >>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both >>>>>>> (PPC). >>>>>>>>>>>> >>>>>>>>>>>> But I don't think it is necessary to do any further changes >>>>>>>>>>>> now, >>>>>>> assuming >>>>>>>>>>>> my change works for you as I adapted it. So we're all set I >>>>>>>>>>>> guess! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>> Barrett >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>> files. >>>>>>>>>>>>> >>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >>>>> kind >>>>>>> of >>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>> Aarch64 >>>>>>>>> port >>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>> Open >>>>>>> port >>>>>>>>>>> use >>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>> just >>>>>>>>> something >>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? >>> You >>>>>>> have >>>>>>>>> to >>>>>>>>>>>>>> check every AARCH change by RedHat against your closed >>> port? >>>>>>>>>>>>> >>>>>>>>>>>>> The sources for the two ports are distinct so the only >>>>>>>>>>>>> place we >>>>> have >>>>>>> to >>>>>>>>>>>>> have a convention is in shared code that has CPU specific >>>>>>>>>>>>> stuff >>> and >>>>> in >>>>>>>>>>>>> the build files. >>>>>>>>>>>>> >>>>>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>> >>>>>>>>>>>>> the closed port sets >>>>>>>>>>>>> >>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>> -DARM >>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>> >>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them. >>>>>>>>>>> Whenever >>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was >>>>> referring >>>>>>> to >>>>>>>>>>> our >>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open >>>>> Aarch64 >>>>>>>>> port. >>>>>>>>>>>>> >>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>>>>>>> >>>>>>>>>>>>> We need to keep a clear distinction. Using the combination of >>>>>>> AARCH64 >>>>>>>>>>>>> and ARM is not so clear. >>>>>>>>>>>>> >>>>>>>>>>>>> You could easily have similar issues with other port groups >>>>>>>>>>>>> - eg >>>>> ppc64 >>>>>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up >>> recently, >>>>>>> and >>>>>>>>>>>>>> before that it sure was equivalent. And it still is the >>>>>>>>>>>>>> case for >>>>>>> openJDK. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Below output is grepped out of the >>> make//platform_ >>>>>>> files >>>>>>>>> in >>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined >>>>> twice. >>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>> D_GNU_SOURCE >>>>>>> - >>>>>>>>>>>>> DAMD64 >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>> D_GNU_SOURCE >>>>>>> - >>>>>>>>>>> DIA32 >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >>>>>>> DCC_INTERP >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >>> DCC_INTERP - >>>>>>>>> DZERO - >>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>>> DAMD64 >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>> DIA32 >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>> runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any >>> further >>>>>>>>> issues, >>>>>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen >>> in >>>>> this >>>>>>>>> new >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>>>>>>> at the same time. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >>>>> kind >>>>>>> of >>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>> Aarch64 >>>>>>>>> port >>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>> Open >>>>>>> port >>>>>>>>>>> use >>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>> just >>>>>>>>> something >>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>> Kim >>>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should >>> be >>>>>>> fixed >>>>>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just >>>>>>>>>>>>>>>>>> that. >>> :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value >>>>> for >>>>>>> the >>>>>>>>>>> ifdef >>>>>>>>>>>>> is >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change that >>>>> value >>>>>>> to >>>>>>>>>>>>> match >>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to >>> other >>>>>>>>>>> problems >>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H >>> macro. >>>>> In >>>>>>>>>>> general >>>>>>>>>>>>> you >>>>>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our >>>>> case >>>>>>>>> ARM >>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In >>> contrast >>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen >>> to >>>>>>>>>>> represent >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>> From: David Holmes >>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>> ; >>>>>>> Kim >>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>> hotspot- >>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>> platform >>>>>>> files. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>> appends >>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>> CPU_HEADER_H, >>>>>>>>> that >>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >>>>> used >>>>>>>>> only >>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do >>> it >>>>> to >>>>>>> get >>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>> need >>>>> not >>>>>>>>> be >>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>> needs >>>>> to >>>>>>> be >>>>>>>>> an >>>>>>>>>>> if- >>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>> in the same statement as the >>> INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from >>> the >>>>>>> closed >>>>>>>>>>> part >>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So >>> we >>>>> get >>>>>>>>> both >>>>>>>>>>>>>>> defined >>>>>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >>>>>>> understand >>>>>>>>>>> what >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to >>>>> be, >>>>>>> as >>>>>>>>> we >>>>>>>>>>>>> are >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the >>>>>>>>>>>>>>>>>>>> current >>>>>>> problem, >>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>> ; >>>>>>>>> Kim >>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>> hotspot- >>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>> platform >>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more >>>>>>>>>>>>>>>>>>>>>>> detail! >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>> ; >>>>>>>>>>> Kim >>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>> hotspot- >>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>> platform >>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz >>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>> >>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications >>> and >>>>>>>>>>> comments >>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch >>>>> directory, >>>>>>> but >>>>>>>>> I >>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. >>>>>>> (Sorry I >>>>>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what >>> needs >>>>> to >>>>>>>>> be >>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this >>> :).) >>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory >>> that >>>>> has >>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >>>>>>> header >>>>>>>>>>> files if >>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches >>>>>>>>> internally >>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not >>>>> hold: >>>>>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was >>> a >>>>>>>>> common >>>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to >>> avoid >>>>> this >>>>>>>>> kind >>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >>>>> TARGET_SO... >>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be >>> moved >>>>> to >>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >>>>>>> elided >>>>>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is >>> the >>>>>>>>>>> umbrella >>>>>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>> appends >>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>> CPU_HEADER_H, >>>>>>>>> that >>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >>>>> used >>>>>>>>> only >>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do >>> it >>>>> to >>>>>>> get >>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>> need >>>>> not >>>>>>>>> be >>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>> needs >>>>> to >>>>>>> be >>>>>>>>> an >>>>>>>>>>> if- >>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of >>> WINDOWS? Is >>>>>>> that >>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>>>>>>> WINDOWS >>>>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is >>>>> defining >>>>>>> - >>>>>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, >>>>> but >>>>>>> not >>>>>>>>> in >>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >>>>>>> unused >>>>>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty >>> file. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> ; >>>>>>>>>>> Kim >>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>>> hotspot- >>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>> platform >>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz >>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's >>>>> working >>>>>>> on >>>>>>>>> all >>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the >>>>>>> macros >>>>>>>>> and >>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>>>>>>> construction >>>>>>>>>>>>> are >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >>>>> macros.hpp. >>>>>>> But >>>>>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and >>> uses >>>>>>> the >>>>>>>>>>> very >>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could >>>>> include >>>>>>>>> that >>>>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as >>>>> fine >>>>>>>>> with >>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is >>> that >>>>>>> the >>>>>>>>>>> linux=1 >>>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros >>> should >>>>> be >>>>>>>>>>> upper >>>>>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>>>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; >>>>> hotspot- >>>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>> including >>>>>>>>>>> platform >>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, >>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these >>> macros >>>>> are >>>>>>>>> only >>>>>>>>>>>>> used >>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody >>>>> needs >>>>>>> to >>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp >>>>> and >>>>>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to >>>>>>> spend >>>>>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted >>> my >>>>>>>>> current >>>>>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to >>> do >>>>> is >>>>>>>>> adding >>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the >>> includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>>>>>>> proposed >>>>>>>>>>> in >>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email >>>>> thread >>>>>>> for >>>>>>>>>>> me; it >>>>>>>>>>>>>>> looks >>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- >>> compiler- >>>>> dev >>>>>>> but >>>>>>>>>>> not >>>>>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list >>>>> this >>>>>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. >>> I've >>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can >>>>> wait >>>>>>>>> until >>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> --- >>>>> --- >>>>>>> ---- >>>>>>>>> --- >>>>>>>>>>> ---- >>>>>>>>>>>>> --- >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround >>> existing >>>>>>>>> #defines >>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so >>> far: >>>>>>>>> linux=1, >>>>>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the >>>>> leading >>>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>>>>> >>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the >>>>> values. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written >>> as >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >>>>>>> instead >>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) >>> are >>>>>>>>> defined, >>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>>>>>>> underscore >>>>>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >>>>>>> pattern >>>>>>>>>>> for >>>>>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use >>>>> uppercase >>>>>>> for >>>>>>>>>>> the >>>>>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> --- >>>>> --- >>>>>>> ---- >>>>>>>>> --- >>>>>>>>>>> ---- >>>>>>>>>>>>> --- >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> From david.holmes at oracle.com Tue Jul 26 03:52:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Jul 2016 13:52:33 +1000 Subject: RFR: JDK-8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134 In-Reply-To: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> References: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> Message-ID: Looks good! Thanks Jiangli. David On 26/07/2016 9:04 AM, Jiangli Zhou wrote: > Please review the following webrev for JDK-8156959 fix. > > http://cr.openjdk.java.net/~jiangli/8156959/webrev.00/ > > The SensorInfo::has_pending_requests() is not thread safe. It tests '_pending_trigger_count > 0 || _pending_clear_count > 0?. In rare cases, there is a race condition in which the check done by the service thread might return ?false? incorrectly while _pending_trigger_count is incremented to 1 and _pending_clear_count is reset to 0 by other thread. In that case, the 'assert(has_pending_requests(), "Must have pending request?)? in SensorInfo::process_pending_requests() becomes invalid. The fix removes the invalid assert. > > As _pending_trigger_count can only be decremented by the service thread and all other threads can only increment the _pending_trigger_count, the race condition issue of SensorInfo::has_pending_requests() is harmless in other usages. If the service thread fails to catch the pending request (when has_pending_requests() returns false incorrectly), it can catch the it in the next iteration. Please see the JDK-8156959 for detailed analysis. > > Test: JPRT and RBT hotspot_all. > > Thanks, > Jiangli > From jiangli.zhou at oracle.com Tue Jul 26 04:19:11 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 25 Jul 2016 21:19:11 -0700 Subject: RFR: JDK-8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134 In-Reply-To: References: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> Message-ID: Thanks for the review, David! Jiangli > On Jul 25, 2016, at 8:52 PM, David Holmes wrote: > > Looks good! Thanks Jiangli. > > David > > On 26/07/2016 9:04 AM, Jiangli Zhou wrote: >> Please review the following webrev for JDK-8156959 fix. >> >> http://cr.openjdk.java.net/~jiangli/8156959/webrev.00/ >> >> The SensorInfo::has_pending_requests() is not thread safe. It tests '_pending_trigger_count > 0 || _pending_clear_count > 0?. In rare cases, there is a race condition in which the check done by the service thread might return ?false? incorrectly while _pending_trigger_count is incremented to 1 and _pending_clear_count is reset to 0 by other thread. In that case, the 'assert(has_pending_requests(), "Must have pending request?)? in SensorInfo::process_pending_requests() becomes invalid. The fix removes the invalid assert. >> >> As _pending_trigger_count can only be decremented by the service thread and all other threads can only increment the _pending_trigger_count, the race condition issue of SensorInfo::has_pending_requests() is harmless in other usages. If the service thread fails to catch the pending request (when has_pending_requests() returns false incorrectly), it can catch the it in the next iteration. Please see the JDK-8156959 for detailed analysis. >> >> Test: JPRT and RBT hotspot_all. >> >> Thanks, >> Jiangli >> From goetz.lindenmaier at sap.com Tue Jul 26 07:23:58 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Jul 2016 07:23:58 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <77ace7f226544841a2df34afc1119fee@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> Message-ID: Great, thanks a lot again! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 26. Juli 2016 03:13 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 25/07/2016 3:01 PM, David Holmes wrote: > > This all looks good. Approval is now in place. Just waiting for final > > conformation this builds okay for Aarch64 folk. > > That confirmation was sent to compiler-dev so the changes have been > pushed. > > David > > > Thanks, > > David > > > > On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: > >> Hi, > >> > >> > >>> I see the typo was actually much bigger than I thought :) Presumably the > >> Well, I edited it some more ... this time I replaced the webrev in-place, > >> webrev.05 is fixed now. > >> > >> I really should have an aarch64 machine :) > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: David Holmes [mailto:david.holmes at oracle.com] > >>> Sent: Donnerstag, 21. Juli 2016 12:00 > >>> To: Lindenmaier, Goetz ; Kim Barrett > >>> > >>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>> > >>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: > >>>> Hi David, > >>>> > >>>> Copyright of register_definitions_x86.cpp is already fixed in hs-comp, > >>>> I'll skip it to avoid merges. > >>> > >>> This isn't going into hs-comp so I don't know when the two will collide. > >>> I would deal with it anyway - I can just apply the patch without > >>> committing, deal with any merges, and then commit as you. > >>> > >>>> I fixed the others. New webrevs, also with Coleens fixes: > >>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.05/ > >>> > >>> I see the typo was actually much bigger than I thought :) Presumably the > >>> INLCUDE typo caused it to be missed by a global search replace. > >>> > >>>> I also did another zero build configured as follows: > >>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- > >>> variants=zero > >>>> on linuxx86_64. > >>> > >>> Thanks. > >>> > >>> David > >>> > >>>> Best regards, > >>>> Goetz. > >>>> > >>>>> -----Original Message----- > >>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>> Sent: Donnerstag, 21. Juli 2016 05:26 > >>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>> > >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>> > >>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > >>>>>> Hi > >>>>>> > >>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>> newPfmIncl/webrev.04/ > >>>>>> > >>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > >>>>> CompileJvm.gmk > >>>>>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I > >>>>> documented > >>>>>> what I learned about the platform defines in macros.hpp. > >>>>> > >>>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) > >>>>> and > >>>>> the lingering _32 the only nit I have left is a handful of copyright > >>>>> updates: > >>>>> > >>>>> src/cpu/x86/vm/register_definitions_x86.cpp: > >>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > >>>>> src/share/vm/runtime/semaphore.hpp: > >>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: > >>>>> src/cpu/ppc/vm/templateTable_ppc.hpp > >>>>> > >>>>> Then all we need is confirmation that all the open platforms that > >>>>> Oracle > >>>>> doesn't also build (aarch64 and Zero) build and run successfully after > >>>>> this change. > >>>>> > >>>>> I will sponsor this (in case that wasn't clear) but may have to > >>>>> delay it > >>>>> until after we sync up the hs forest with the CPU changes now in > >>>>> jdk9/dev. I will rebase and handle any merging if needed. > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> ----- > >>>>> > >>>>>> Best regards, > >>>>>> Goetz. > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 > >>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>> > >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>> dev at openjdk.java.net > >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>> > >>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> OK, to get this through I will add > >>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>> and revert this one and only place it needs to be used in the > >>>>>>> vmStructs_jvmci.cpp. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such > >>> cleanups > >>>>>>> should > >>>>>>>> not be in this change. > >>>>>>> > >>>>>>> I did not know they had a 64-bit C1 - interesting. > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks for doing the closed changes! > >>>>>>> > >>>>>>> You're welcome. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> David > >>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Goetz. > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>> > >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>> dev at openjdk.java.net > >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>> > >>>>>>>>> Hi Goetz, > >>>>>>>>> > >>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> Hi David, > >>>>>>>>>> > >>>>>>>>>> that's great what you are saying and just the design I would > >>>>>>>>>> expect! > >>>>>>>>>>> We did not want to have to > >>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit > >>> ARM" > >>>>> so > >>>>>>>>>>> we worked with the Open port to ensure that shared code > >>> guarded > >>>>> by > >>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used > to > >>>>>>> identify > >>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a > handful of > >>>>>>> places > >>>>>>>>>>> that needed it. And sometimes we have to be careful and > ensure > >>>>> that > >>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>>>> > >>>>>>>>>> I think as a consequence the open AARCH port should define > ARM, > >>>>> too. > >>>>>>>>> > >>>>>>>>> I would not want to do this and certainly not as part of this > >>>>>>>>> change. > >>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, > >>>>>>>>> but not > >>>>>>>>> right now, please. > >>>>>>>>> > >>>>>>>>>> I checked the occurrences and only see three places where this > >>> would > >>>>>>> have > >>>>>>>>>> an effect and would have to be fixed somehow: > >>>>>>>>>> > >>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>>>>>>> [610] #if defined(AARCH64) && > >>>>>>>>>> !defined(ARM) > >>>>>>>>>> ==> Would this break the closed port if defined? > >>>>>>>>> > >>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 > >>>>>>>>> sources. > >>>>>>>>> > >>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was > >>> used) > >>>>>>>>>> > >>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>>>>>>> load_item_force[253] #if !defined(ARM) && > >>>>>>>>>> !defined(E500V2) > >>>>>>>>>> ==> Would this break the open port if defined? > >>>>>>>>>> > >>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>>>>>>> [1154] #ifdef ARM > >>>>>>>>>> ==> Would this break the open port if defined? > >>>>>>>>> > >>>>>>>>> I don't think the open port has C1 so it would ignore the above > >>>>>>>>> files > >>>>>>>>> anyway. > >>>>>>>>> > >>>>>>>>>> All the cases below are pointless. > >>>>>>>>>> > >>>>>>>>>>> So what I'm suggesting is just not getting rid of those > >>>>>>>>>>> defines, but > >>>>>>>>>>> keeping them so they can be used as include guards (or other > >>>>>>> conditional > >>>>>>>>>>> code) when needed, and where the macros are not suitable. > >>>>>>>>>> I think it's quite misleading to have two defines that are 99% > >>>>> equivalent. > >>>>>>>>>> If we really need a special case here, you should define - > >>>>> DARM_CLOSED > >>>>>>>>>> or the like in your closed port. Such a name would make clear > >>> what's > >>>>> the > >>>>>>>>>> issue. At least, only your closed port has this problem. > >>>>>>>>> > >>>>>>>>> I really do not want to make any changes to this - ignoring the > >>> include > >>>>>>>>> macro changes everything we have is working perfectly fine just > >>>>>>>>> the > >>>>> way > >>>>>>>>> the defines are. So I don't want to see this change potentially > >>>>>>>>> break > >>>>>>>>> that through incidental changes. > >>>>>>>>> > >>>>>>>>> I do not see having the following is a big issue: > >>>>>>>>> > >>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>> > >>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, > and > >>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that > define > >>>>> intend > >>>>>>> it to > >>>>>>>>> mean. It certainly is a lot better than interpreting what the > >>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes > the > >>>>>>> need to > >>>>>>>>> perform some of the changes as noted above. > >>>>>>>>> > >>>>>>>>> I'm preparing the review of the internal changes we need to > >>>>> accompany > >>>>>>> this. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> These should not break the open port if ARM gets defined, or > can > >>> be > >>>>>>> fixed > >>>>>>>>> easily. > >>>>>>>>>> --------------------------------------------------------- > >>>>>>>>>> > >>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>>>>> print[1519] #elif defined(ARM) > >>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>>>>> > >>>>>>>>>> *** os/linux/vm/os_linux.cpp: > >>>>>>>>>> dll_load[1796] #elif (defined ARM) > >>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>>>>> > >>>>>>>>>> *** share/vm/opto/matcher.cpp: > >>>>>>>>>> init_first_stack_mask[558] #ifdef ARM > >>>>>>>>>> ==> Should be ARM32 (Is under !LP64). > >>>>>>>>>> > >>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == > >>>>>>>>>> cpu_register) > >>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == > >>>>>>>>>> cpu_register) > >>>>>>>>>> ==> Just an assertion. Will just relax the check if defined > >>>>>>>>>> in open > >>>>>>> AARCH64. > >>>>>>>>>> But maybe should be guarded by __SOFTFP__. > >>>>>>>>>> [70] #if defined(ARM) || > >>>>>>>>>> defined(AARCH64) || > >>>>>>>>> defined(PPC64) > >>>>>>>>>> ==> Fine: || > >>>>>>>>>> > >>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>>>>>>> [447] #if defined(SPARC) || > >>>>>>>>>> defined(ARM) || > >>>>>>>>> defined(PPC) || defined(AARCH64) > >>>>>>>>>> [537] #if defined(X86) || > >>>>>>>>>> defined(ARM) || > >>>>>>>>> defined(AARCH64) > >>>>>>>>>> ==> Fine: || > >>>>>>>>>> > >>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>>>>>>> defined[162] #if defined(IA32) || > >>>>>>>>>> defined(AMD64) || > >>>>>>>>> defined(ARM) > >>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>>>>>>> [1358] #if defined(IA32) || > >>>>>>>>>> defined(AMD64) || > >>>>>>>>> defined(ARM) > >>>>>>>>>> ==> Just defines a method which would be unused, should be > fine. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> These are in code not used in the open AARCH64 port: > >>>>>>>>>> -------------------------------------------------- > >>>>>>>>>> > >>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>>>>> [215] #elif defined(ARM) > >>>>>>>>>> > >>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>>>>> [102] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>>>>>>> [31] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>>>>> [102] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> *** > os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>>>>>>> [31] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> *** share/vm/utilities/macros.hpp: > >>>>>>>>>> [434] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>>>>> dll_load[1508] #elif (defined ARM) > >>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, > >>>>>>>>>> __powerpc__, > >>>>> ARM, > >>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>>>>>>> > >>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>>>>>>> dll_load[1725] #elif (defined ARM) > >>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, > >>>>>>>>>> __powerpc__, > >>>>> ARM, > >>>>>>>>> ARM > >>>>>>>>>> > >>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>>>>> store[164] #if !defined(ARM) && > >>>>>>>>>> !defined(M68K) > >>>>>>>>>> store_ptr[171] #if !defined(ARM) && > >>>>>>>>>> !defined(M68K) > >>>>>>>>>> add[178] #ifdef ARM > >>>>>>>>>> add_ptr[190] #ifdef ARM > >>>>>>>>>> xchg[230] #ifdef ARM > >>>>>>>>>> xchg_ptr[253] #ifdef ARM > >>>>>>>>>> cmpxchg[275] #ifdef ARM > >>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>>>>> add[172] #ifdef ARM > >>>>>>>>>> add_ptr[184] #ifdef ARM > >>>>>>>>>> xchg[224] #ifdef ARM > >>>>>>>>>> xchg_ptr[247] #ifdef ARM > >>>>>>>>>> cmpxchg[269] #ifdef ARM > >>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >>> Barrett > >>>>>>>>>>> > >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>> > >>>>>>>>>>> Hi Goetz, > >>>>>>>>>>> > >>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>> Hi David, > >>>>>>>>>>>> > >>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. > >>>>>>>>>>>> (Parisc is gone, puh!). > >>>>>>>>>>>> We basically patch all the shared changes onto the sources > >>>>>>>>>>>> after > >>>>>>>>>>>> getting them via our licensee channel. > >>>>>>>>>>>> I think you should fix your closed port not to re-use the > >>>>>>>>>>>> names of > >>>>> the > >>>>>>>>>>>> main openJdk platforms! > >>>>>>>>>>> > >>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not > want to > >>>>> have > >>>>>>> to > >>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit > >>> ARM" > >>>>> so > >>>>>>>>>>> we worked with the Open port to ensure that shared code > >>> guarded > >>>>> by > >>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used > to > >>>>>>> identify > >>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a > handful of > >>>>>>> places > >>>>>>>>>>> that needed it. And sometimes we have to be careful and > ensure > >>>>> that > >>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>>>>> > >>>>>>>>>>> This has all been working quite nicely, as the include guards > >>>>>>>>>>> used, > >>> for > >>>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM > - > >>> which > >>>>>>> are > >>>>>>>>>>> never > >>>>>>>>>>> defined at the same time (derived from > >>>>>>> HOTSPOT_TARGET_CPU_ARCH). > >>>>>>>>> But > >>>>>>>>>>> the > >>>>>>>>>>> current changes remove those unique defines and, before > the > >>>>>>> HEADER_H > >>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and > ARM as > >>>>>>> include > >>>>>>>>>>> guards, and that doesn't work as they are not mutually > >>>>>>>>>>> exclusive. > >>>>>>>>>>> > >>>>>>>>>>> So what I'm suggesting is just not getting rid of those > >>>>>>>>>>> defines, but > >>>>>>>>>>> keeping them so they can be used as include guards (or other > >>>>>>> conditional > >>>>>>>>>>> code) when needed, and where the macros are not suitable. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> David > >>>>>>>>>>> ----- > >>>>>>>>>>> > >>>>>>>>>>>> I have no idea what hardware is addressed by your closed > ports, > >>>>>>>>>>>> nor how you merge sources. > >>>>>>>>>>>> Is there also a port that sets > >>>>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>>>> -DARM > >>>>>>>>>>>> -DARM32 > >>>>>>>>>>>> ? > >>>>>>>>>>>> > >>>>>>>>>>>> To fix this either you define > >>>>>>>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>>>>>>> #define ARM64 > >>>>>>>>>>>> #endif > >>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>>>>>>>>> Then you replace all > >>>>>>>>>>>> #ifdef AARCH64 > >>>>>>>>>>>> by > >>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>>>>>>> or maybe it suffices altogether f you replace > >>>>>>>>>>>> #ifdef AARCH64 > >>>>>>>>>>>> by > >>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>>>>>>> > >>>>>>>>>>>> For ppc, when we did the port we knew (and that's all we > knew) > >>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these > macros > >>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for > >>>>>>> LP64/!LP64 > >>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed > >>>>>>>>>>>> port > >>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for > both > >>>>>>> (PPC). > >>>>>>>>>>>> > >>>>>>>>>>>> But I don't think it is necessary to do any further changes > >>>>>>>>>>>> now, > >>>>>>> assuming > >>>>>>>>>>>> my change works for you as I adapted it. So we're all set I > >>>>>>>>>>>> guess! > >>>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Goetz. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>>> Barrett > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>>> files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. > This > >>>>> kind > >>>>>>> of > >>>>>>>>>>>>>>> workaround is obscure - you have to know that the > Open > >>>>> Aarch64 > >>>>>>>>> port > >>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for > the > >>> Open > >>>>>>> port > >>>>>>>>>>> use > >>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - > >>>>>>>>>>>>>>> just > >>>>>>>>> something > >>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be > restored? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle > that? > >>> You > >>>>>>> have > >>>>>>>>> to > >>>>>>>>>>>>>> check every AARCH change by RedHat against your closed > >>> port? > >>>>>>>>>>>>> > >>>>>>>>>>>>> The sources for the two ports are distinct so the only > >>>>>>>>>>>>> place we > >>>>> have > >>>>>>> to > >>>>>>>>>>>>> have a convention is in shared code that has CPU specific > >>>>>>>>>>>>> stuff > >>> and > >>>>> in > >>>>>>>>>>>>> the build files. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>>>>>>> -DAARCH64 > >>>>>>>>>>>>> > >>>>>>>>>>>>> the closed port sets > >>>>>>>>>>>>> > >>>>>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>>>>> -DARM > >>>>>>>>>>>>> -DAARCH64 > >>>>>>>>>>>>> > >>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes > them. > >>>>>>>>>>> Whenever > >>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was > >>>>> referring > >>>>>>> to > >>>>>>>>>>> our > >>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open > >>>>> Aarch64 > >>>>>>>>> port. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same > position. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We need to keep a clear distinction. Using the combination > of > >>>>>>> AARCH64 > >>>>>>>>>>>>> and ARM is not so clear. > >>>>>>>>>>>>> > >>>>>>>>>>>>> You could easily have similar issues with other port groups > >>>>>>>>>>>>> - eg > >>>>> ppc64 > >>>>>>>>>>>>> vs ppc32 vs ppcle. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> David > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up > >>> recently, > >>>>>>> and > >>>>>>>>>>>>>> before that it sure was equivalent. And it still is the > >>>>>>>>>>>>>> case for > >>>>>>> openJDK. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Below output is grepped out of the > >>> make//platform_ > >>>>>>> files > >>>>>>>>> in > >>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are > defined > >>>>> twice. > >>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DAMD64 > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >>>>> D_GNU_SOURCE > >>>>>>> - > >>>>>>>>>>>>> DAMD64 > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >>>>> D_GNU_SOURCE > >>>>>>> - > >>>>>>>>>>> DIA32 > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - > >>>>>>> DCC_INTERP > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >>> DCC_INTERP - > >>>>>>>>> DZERO - > >>>>>>>>>>>>> D at ZERO_ARCHDEF@ - > >>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > >>>>> DAMD64 > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - > >>> DIA32 > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP - > DZERO - > >>>>>>>>>>>>> D at ZERO_ARCHDEF@ - > >>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>>>>> Barrett > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >>> runtime- > >>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any > >>> further > >>>>>>>>> issues, > >>>>>>>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and > Coleen > >>> in > >>>>> this > >>>>>>>>> new > >>>>>>>>>>>>>>> webrev: > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are > defined > >>>>>>>>>>>>>>>> at the same time. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. > This > >>>>> kind > >>>>>>> of > >>>>>>>>>>>>>>> workaround is obscure - you have to know that the > Open > >>>>> Aarch64 > >>>>>>>>> port > >>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for > the > >>> Open > >>>>>>> port > >>>>>>>>>>> use > >>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - > >>>>>>>>>>>>>>> just > >>>>>>>>> something > >>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be > restored? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>> Kim > >>>>>>>>> Barrett > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>> runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>> files. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this > should > >>> be > >>>>>>> fixed > >>>>>>>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just > >>>>>>>>>>>>>>>>>> that. > >>> :) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the > value > >>>>> for > >>>>>>> the > >>>>>>>>>>> ifdef > >>>>>>>>>>>>> is > >>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change > that > >>>>> value > >>>>>>> to > >>>>>>>>>>>>> match > >>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to > >>> other > >>>>>>>>>>> problems > >>>>>>>>>>>>> as > >>>>>>>>>>>>>>>>>> we also need that value the way it is currently > defined. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H > >>> macro. > >>>>> In > >>>>>>>>>>> general > >>>>>>>>>>>>> you > >>>>>>>>>>>>>>>>> can't just replace: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In > our > >>>>> case > >>>>>>>>> ARM > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In > >>> contrast > >>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is > chosen > >>> to > >>>>>>>>>>> represent > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>> From: David Holmes > >>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>> ; > >>>>>>> Kim > >>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>> hotspot- > >>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>> platform > >>>>>>> files. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it > >>> appends > >>>>>>> .hpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >>>>> CPU_HEADER_H, > >>>>>>>>> that > >>>>>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will > be > >>>>> used > >>>>>>>>> only > >>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should > do > >>> it > >>>>> to > >>>>>>> get > >>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names > >>> need > >>>>> not > >>>>>>>>> be > >>>>>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this > >>> needs > >>>>> to > >>>>>>> be > >>>>>>>>> an > >>>>>>>>>>> if- > >>>>>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are > set in > >>>>>>>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>> in the same statement as the > >>> INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in > from > >>> the > >>>>>>> closed > >>>>>>>>>>> part > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. > So > >>> we > >>>>> get > >>>>>>>>> both > >>>>>>>>>>>>>>> defined > >>>>>>>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to > >>>>>>> understand > >>>>>>>>>>> what > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is > intended to > >>>>> be, > >>>>>>> as > >>>>>>>>> we > >>>>>>>>>>>>> are > >>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the > >>>>>>>>>>>>>>>>>>>> current > >>>>>>> problem, > >>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>> ; > >>>>>>>>> Kim > >>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>>> hotspot- > >>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>> platform > >>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more > >>>>>>>>>>>>>>>>>>>>>>> detail! > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>> ; > >>>>>>>>>>> Kim > >>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > dev at openjdk.java.net; > >>>>>>> hotspot- > >>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > including > >>>>>>> platform > >>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz > >>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of > clarifications > >>> and > >>>>>>>>>>> comments > >>>>>>>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU > to > >>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch > >>>>> directory, > >>>>>>> but > >>>>>>>>> I > >>>>>>>>>>>>> don't > >>>>>>>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated > files. > >>>>>>> (Sorry I > >>>>>>>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what > >>> needs > >>>>> to > >>>>>>>>> be > >>>>>>>>>>>>>>> changed > >>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send > this > >>> :).) > >>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory > >>> that > >>>>> has > >>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to > >>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more > _32/_64 > >>>>>>> header > >>>>>>>>>>> files if > >>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that > dispatches > >>>>>>>>> internally > >>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did > not > >>>>> hold: > >>>>>>>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways > was > >>> a > >>>>>>>>> common > >>>>>>>>>>> file > >>>>>>>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to > >>> avoid > >>>>> this > >>>>>>>>> kind > >>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, > pc); > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in > >>>>> TARGET_SO... > >>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be > >>> moved > >>>>> to > >>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can > simply be > >>>>>>> elided > >>>>>>>>>>> here ?? > >>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which > is > >>> the > >>>>>>>>>>> umbrella > >>>>>>>>>>>>>>> header > >>>>>>>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed > anyways. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it > >>> appends > >>>>>>> .hpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >>>>> CPU_HEADER_H, > >>>>>>>>> that > >>>>>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will > be > >>>>> used > >>>>>>>>> only > >>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should > do > >>> it > >>>>> to > >>>>>>> get > >>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names > >>> need > >>>>> not > >>>>>>>>> be > >>>>>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this > >>> needs > >>>>> to > >>>>>>> be > >>>>>>>>> an > >>>>>>>>>>> if- > >>>>>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of > >>> WINDOWS? Is > >>>>>>> that > >>>>>>>>>>>>> coming > >>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I > defined > >>>>>>>>> WINDOWS > >>>>>>>>>>> in > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is > >>>>> defining > >>>>>>> - > >>>>>>>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS > instead. > >>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by > WINDOWS, > >>>>> but > >>>>>>> not > >>>>>>>>> in > >>>>>>>>>>> this > >>>>>>>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed > the > >>>>>>> unused > >>>>>>>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty > >>> file. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>> ; > >>>>>>>>>>> Kim > >>>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > dev at openjdk.java.net; > >>>>>>>>> hotspot- > >>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > including > >>>>>>>>> platform > >>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, > Goetz > >>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's > >>>>> working > >>>>>>> on > >>>>>>>>> all > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in > the > >>>>>>> macros > >>>>>>>>> and > >>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the > name > >>>>>>>>>>> construction > >>>>>>>>>>>>> are > >>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in > >>>>> macros.hpp. > >>>>>>> But > >>>>>>>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, > and > >>> uses > >>>>>>> the > >>>>>>>>>>> very > >>>>>>>>>>>>>>> same > >>>>>>>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one > could > >>>>> include > >>>>>>>>> that > >>>>>>>>>>> in > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am > as > >>>>> fine > >>>>>>>>> with > >>>>>>>>>>> your > >>>>>>>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better > is > >>> that > >>>>>>> the > >>>>>>>>>>> linux=1 > >>>>>>>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros > >>> should > >>>>> be > >>>>>>>>>>> upper > >>>>>>>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >>>>>>> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; > >>>>> hotspot- > >>>>>>>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > >>> including > >>>>>>>>>>> platform > >>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, > Lindenmaier, > >>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these > >>> macros > >>>>> are > >>>>>>>>> only > >>>>>>>>>>>>> used > >>>>>>>>>>>>>>>>> within > >>>>>>>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code > everybody > >>>>> needs > >>>>>>> to > >>>>>>>>>>>>>>> understand > >>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file > bytes.hpp > >>>>> and > >>>>>>>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for > cpu/os/os_cpu > >>>>>>>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have > to > >>>>>>> spend > >>>>>>>>> days > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and > posted > >>> my > >>>>>>>>> current > >>>>>>>>>>>>>>> progress > >>>>>>>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need > to > >>> do > >>>>> is > >>>>>>>>> adding > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the > >>> includes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what > Volker > >>>>>>>>> proposed > >>>>>>>>>>> in > >>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the > email > >>>>> thread > >>>>>>> for > >>>>>>>>>>> me; it > >>>>>>>>>>>>>>> looks > >>>>>>>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- > >>> compiler- > >>>>> dev > >>>>>>> but > >>>>>>>>>>> not > >>>>>>>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the > compiler list > >>>>> this > >>>>>>>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over > details. > >>> I've > >>>>>>> only > >>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it > can > >>>>> wait > >>>>>>>>> until > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------ > ----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>> --- > >>>>> --- > >>>>>>> ---- > >>>>>>>>> --- > >>>>>>>>>>> ---- > >>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround > >>> existing > >>>>>>>>> #defines > >>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected > so > >>> far: > >>>>>>>>> linux=1, > >>>>>>>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the > >>>>> leading > >>>>>>>>>>>>> underscore > >>>>>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. > in > >>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += > \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>>>>>>>>> > >>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the > >>>>> values. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be > written > >>> as > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) > >>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants > brackets > >>>>>>> instead > >>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for > example) > >>> are > >>>>>>>>> defined, > >>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note > that > >>>>>>>>> underscore > >>>>>>>>>>>>>>>>> followed > >>>>>>>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved > word > >>>>>>> pattern > >>>>>>>>>>> for > >>>>>>>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use > >>>>> uppercase > >>>>>>> for > >>>>>>>>>>> the > >>>>>>>>>>>>>>> macro > >>>>>>>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about > that. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------ > ----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>> --- > >>>>> --- > >>>>>>> ---- > >>>>>>>>> --- > >>>>>>>>>>> ---- > >>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> From mikael.gerdin at oracle.com Tue Jul 26 08:48:49 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Jul 2016 10:48:49 +0200 Subject: RFR (XS): 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: <1469434464.4325.4.camel@oracle.com> References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> <1469106305.4338.24.camel@oracle.com> <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> <1469187356.4267.12.camel@oracle.com> <6b4492b4-4d9f-6a1c-841c-231fab3ca282@oracle.com> <1469434464.4325.4.camel@oracle.com> Message-ID: Hi Thomas, On 2016-07-25 10:14, Thomas Schatzl wrote: > Hi David, > > On Mon, 2016-07-25 at 15:06 +1000, David Holmes wrote: >> On 22/07/2016 9:35 PM, Thomas Schatzl wrote: >>> >>> Hi David, >>> > [...] >>>>>> Also if we log the initial_active_count we should log the >>>>>> _processor_count too. >>>>> I can log both in log messages and the error log - although >>>>> processor >>>>> count information is already in the log. >>>> With the new proposal I would just add the logging to >>>> set_initial_active_processor_count(). >>> New webrev: >>> http://cr.openjdk.java.net/~tschatzl/8161993/webrev.1/ (full, it's >>> 5 >>> lines now, so I did not bother creating a diff webrev) >> Looks good! Looks good to me as well. /Mikael > > thanks for the review. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Tue Jul 26 08:59:27 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 26 Jul 2016 10:59:27 +0200 Subject: RFR (XS): 8161993: G1 crashes if active_processor_count changes during startup In-Reply-To: References: <1469100481.4338.18.camel@oracle.com> <5f26ed5a-0457-198e-3460-3fd3af066b71@oracle.com> <1469106305.4338.24.camel@oracle.com> <0de396b2-284b-baf4-5528-c6f030c3d041@oracle.com> <1469187356.4267.12.camel@oracle.com> <6b4492b4-4d9f-6a1c-841c-231fab3ca282@oracle.com> <1469434464.4325.4.camel@oracle.com> Message-ID: <1469523567.4448.2.camel@oracle.com> Hi Mikael, On Tue, 2016-07-26 at 10:48 +0200, Mikael Gerdin wrote: > Hi Thomas, > > > > > > > > [...] > > > > > > > Also if we log the initial_active_count we should log the > > > > > > > _processor_count too. > > > > > > I can log both in log messages and the error log - although > > > > > > processor > > > > > > count information is already in the log. > > > > > With the new proposal I would just add the logging to > > > > > set_initial_active_processor_count(). > > > > New webrev: > > > > http://cr.openjdk.java.net/~tschatzl/8161993/webrev.1/ (full, > > > > it's > > > > 5 > > > > lines now, so I did not bother creating a diff webrev) > > > Looks good! > Looks good to me as well. ? thanks for your review. Thomas From lois.foltan at oracle.com Tue Jul 26 13:58:37 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 26 Jul 2016 09:58:37 -0400 Subject: RFR (L) JDK-8154239: -Xbootclasspath/a breaks exploded build In-Reply-To: <6F26E4C1-15D5-4F46-BCF7-6161D5A510F2@oracle.com> References: <578E6CBC.9010901@oracle.com> <57913A92.6040001@oracle.com> <4E460683-7439-4AC9-A79A-B1229CCF351C@oracle.com> <57965C99.5020200@oracle.com> <6F26E4C1-15D5-4F46-BCF7-6161D5A510F2@oracle.com> Message-ID: <57976C8D.8040305@oracle.com> On 7/25/2016 5:01 PM, Jiangli Zhou wrote: > Hi Lois, > >> On Jul 25, 2016, at 11:38 AM, Lois Foltan wrote: >> >> >> On 7/22/2016 6:45 PM, Jiangli Zhou wrote: >>> Hi Lois, >>> >>> This looks really good. I have one very minor comment for ClassLoader::add_to_list(). How about adding an assert to make sure _first_append_entry is also NULL under ?if (_last_append_entry == NULL)? before setting the entries? >> Done. >> >> Thanks for the review Jiangli! For completeness, here is a webrev that incorporates all review comments: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.2/webrev/ > Looks good. Thank you for adding the exploded module build checks in FileMapHeader::validate() and Arguments::check_unsupported_dumping_properties(). Thanks Jiangli for the review! Lois > > Thanks, > Jiangli > >> Lois >> >>> Thanks, >>> Jiangli >>> >>> >>>> On Jul 21, 2016, at 2:11 PM, Lois Foltan wrote: >>>> >>>> >>>> On 7/21/2016 11:25 AM, harold seigel wrote: >>>>> Hi Lois, >>>>> >>>>> This is a nice fix for the exploded build system class path issues! >>>>> >>>>> If the callers of methods such as add_to_exploded_build_list() already have THREAD, can it be passed as a parameter? >>>> Done. >>>> >>>>> In classLoader.cpp, the comment at lines 1466 - 1468 say that the starting classpath_index is always 1. Can you either add an assert for this or change line 1469 to just: classpath_index = 1; >>>> Done. >>>> >>>>> In classLoader.hpp, could has_jimage() be renamed to something like has_jrt_entry so it's not confused with the has_jimage() method in arguments.hpp? >>>> Done. >>>> >>>>> In filemap.cpp, can the code at lines 226 - 230 be changed to: >>>>> >>>>> assert(strptr + name_bytes <= strptr_max, "miscalculated buffer size"); >>>>> strncpy(...) >>>>> strptr += name_bytes; >>>> Done. >>>> >>>> Thanks for the review Harold! New webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239.1/webrev/ >>>> Lois >>>> >>>>> Thanks, Harold >>>>> >>>>> >>>>> On 7/19/2016 2:09 PM, Lois Foltan wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following fix: >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8154239/webrev/ >>>>>> >>>>>> Bug: -Xbootclasspath/a breaks exploded build >>>>>> https://bugs.openjdk.java.net/browse/JDK-8154239 >>>>>> >>>>>> Summary: >>>>>> The JVM was incorrectly handling how to set up and search the ClassPathEntry's for directories representing the module definitions in an exploded module build situation for the boot class loader. The incorrect set up and search was particularly exposed when -Xbootclasspath/a was specified in conjunction with a exploded module build. In an exploded module build, when Modules::define_modules was called to define a module to the boot loader, a ClassPathEntry was simply appended to the boot loader's search list. At load class time, a class would then be searched by simply traversing that list without any regards to the module that class was defined in. This is incorrect behavior. The class should only be searched for in the location of the module's definition that it was defined within. The fix now records each module and it's exploded build location in order to adhere to this rule. >>>>>> >>>>>> The other piece to this problem was that if -Xbootclasspath/a was specified, it was incorrectly injected prior to the majority of ClassPathEntry's for the exploded modules, yielding a broken and incorrect search order for the boot loader. Introducing the concept of a "base" or "core" piece for the boot loader which is either the java runtime image or the exploded modules build and changing the ClassLoader::_first_append_entry to truly be only appended entries added via -Xbootclasspath/a or jvmti appended entries, introduces a clean way for how this information is stored in the ClassLoader data structure that maps directly to how ClassLoader::load_class() searches that information. >>>>>> >>>>>> 215 // The boot class path consists of 3 ordered pieces: >>>>>> 216 // 1. the module/path pairs specified to -Xpatch >>>>>> 217 // -Xpatch:=()* >>>>>> 218 // 2. the base piece >>>>>> 219 // [jimage | build with exploded modules] >>>>>> 220 // 3. boot loader append path >>>>>> 221 // [-Xbootclasspath/a]; [jvmti appended entries] >>>>>> 222 // >>>>>> 223 // The boot loader must obey this order when attempting >>>>>> 224 // to load a class. >>>>>> >>>>>> >>>>>> Testing: >>>>>> Full hotspot nightly testing with a java runtime image build >>>>>> JDK java/io, java/lang, java/util with both a java runtime image and an exploded module build >>>>>> JCK lang & vm with both a java runtime image and an exploded module build >>>>>> Hotspot jtreg tests with both a java runtime image and an exploded module build >>>>>> >> From karen.kinnear at oracle.com Tue Jul 26 15:22:31 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 26 Jul 2016 11:22:31 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <8b684da0-6911-3f98-867f-5abdbf8c569a@oracle.com> References: <8b684da0-6911-3f98-867f-5abdbf8c569a@oracle.com> Message-ID: Coleen & David, Thank you for the review comments. I clarified the comments in all three methods to the appropriate match on: // Be careful when modifying this code: once you have run placeholders()->find_and_add(PlaceholderTable::LOAD_SUPER), // you need to find_and_remove it before returning. So be careful to not exit with a CHECK_ macro betweeen these calls. Let me know if you want to see an updated web rev. > On Jul 22, 2016, at 2:04 AM, David Holmes wrote: > > Hi Karen, > > Generally this looks good. A couple of comments below ... > > On 22/07/2016 3:23 AM, Karen Kinnear wrote: >> Please review: >> https://bugs.openjdk.java.net/browse/JDK-8162340 >> >> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ > > src/share/vm/classfile/systemDictionary.cpp > > 336 // leave PENDING_EXCEPTION handling in this code to ensure we do the placeholder cleanup (find_and_remove) > 337 // and do not throw exceptions while holding locks > > Nit: can you rebalance the lines, the first is rather long. > > It is unclear to me what this comment means given the following code barely references PENDING_EXCEPTION - AFAICS just the end check at: > > 415 if (HAS_PENDING_EXCEPTION || superk_h() == NULL) { > > Does it really mean "Don't use CHECK_ macros to ensure we do the placeholder cleanuop ..." ? > > Similarly with: > > 642 // leave PENDING_EXCEPTION handling in this code to ensure we do the placeholder cleanup (find_and_remove) > 643 // and do not throw exceptions while holding locks > > Though in that case we have: > > 722 k = SystemDictionary::handle_parallel_super_load(name, superclassname, > 723 class_loader, protection_domain, lockObject, THREAD); > 724 if (HAS_PENDING_EXCEPTION) { > 725 return NULL; > > in which case we could be using CHECK_NULL anyway. > > Similarly: > > 1665 // leave PENDING_EXCEPTION handling in this code to ensure we do the placeholder cleanup (find_and_remove) > 1666 // and do not throw exceptions while holding locks > > Again not clear what it refers to as we don't have the pattern "if (!HAS_PENDING_EXCEPTION) ..." that was removed elsewhere. And we do have some uses of check macros. I thought about making this comment as well, and can I suggest that these comments be moved closer to the code they are trying to describe: In resolve_super_or_fail, it should be before the call to resolve_or_null(). In resolve_instance_klass_or_null, it should be before the call to load_instance_klass(). Then they'll make sense and they won't get lost with the large comments, and the one before the function definition which isn't true. Also, it's a bit of unfortunate API that the dictionary and placeholder functions take a last THREAD parameter since it looks like you're ignoring a pending exception, but they don't throw exceptions. As a future cleanup, THREAD should be first there to eliminate this confusion. Or add Thread* thread = THREAD; at the top and use this version for these calls. As a future cleanup if you wish. Thanks, Coleen See comment about for response - which hopefully is much clearer. I fixed the comment, left it at the top since people should be in the habit of reading global comments for a function even if they might miss some embedded comments. I left THREAD at the end since if you are not within the find_and_add/find_and_remove you can use the CHECK_ macro. > --- > > src/share/vm/oops/instanceKlass.cpp > > + // ensure java/ packages only loaded by boot or platform builtin loaders > > Nit: the platform loader need not be a "builtin" loader - can we drop "builtin?? We have a new term for JDK9 - we have three builtin loaders: boot, platform (formerly known as extension) and application. So this platform loader must be a builtin loader. Not to be confused with the system class loader which is the default delegation parent for custom class loaders. thanks, Karen > >> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev > > Is there an existing test for non-anonymous classes that claim to be in the java/ package hierarchy? > > Thanks, > David > ----- > >> When moving the check from resolve_from_stream to set_package, I removed >> the no longer need parsed_class (!) which I should have cleaned up when >> tightening the placeholder table cleanup years ago. >> >> Tests run: >> 1. updated VMAnonymousClass test >> 2. jcks >> 3. rbt hs-nightly-runtime linux-x64 in progress >> >> thanks, >> Karen >> >> From gerald.thornbrugh at oracle.com Tue Jul 26 16:06:03 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 26 Jul 2016 10:06:03 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k Message-ID: <57978A6B.6000906@oracle.com> Hi Everyone, I would like to have the following change reviewed: Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ The stack size for this test needs to be increased to 384K for some platforms. My fix for JDK-8081770 https://bugs.openjdk.java.net/browse/JDK-8081770 moved the functionality from the testme.sh script to exeinvoke.c so the dependency for a local compiler could be removed. Because of this the stack size change needs to be applied to exeinvoke.c file instead of the testme.sh file. Please let me know if you have any questions or concerns. Thanks, Jerry From daniel.daugherty at oracle.com Tue Jul 26 17:16:09 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Jul 2016 11:16:09 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <57978A6B.6000906@oracle.com> References: <57978A6B.6000906@oracle.com> Message-ID: <441745ef-2424-4210-2a74-6ba516f34084@oracle.com> On 7/26/16 10:06 AM, Gerald Thornbrugh wrote: > Hi Everyone, > > I would like to have the following change reviewed: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 > > Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ > test/runtime/StackGuardPages/exeinvoke.c No comments. > The stack size for this test needs to be increased to 384K for some > platforms. > My fix for JDK-8081770 > https://bugs.openjdk.java.net/browse/JDK-8081770 moved the functionality > from the testme.sh script to exeinvoke.c so the dependency for a local > compiler could be removed. > Because of this the stack size change needs to be applied to > exeinvoke.c file instead of the testme.sh file. > > Please let me know if you have any questions or concerns. It took me a little bit to figure out how this failure started happening in the first place. My guess is that your fix for JDK-8081770 made it so that the test was now runnable on ARM64, where before it wouldn't run because of the local compiler dependency. Now that a local compiler is not needed, the original -Xss320k is discovered to be insufficient on ARM64. Do I have all this right? Thumbs up pending a reply that shows you have done adequate testing on this fix. Dan > > Thanks, > > Jerry From gerald.thornbrugh at oracle.com Tue Jul 26 17:25:43 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 26 Jul 2016 11:25:43 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <441745ef-2424-4210-2a74-6ba516f34084@oracle.com> References: <57978A6B.6000906@oracle.com> <441745ef-2424-4210-2a74-6ba516f34084@oracle.com> Message-ID: <57979D17.40505@oracle.com> Hi Dan, > On 7/26/16 10:06 AM, Gerald Thornbrugh wrote: >> Hi Everyone, >> >> I would like to have the following change reviewed: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >> >> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >> > > test/runtime/StackGuardPages/exeinvoke.c > No comments. > > >> The stack size for this test needs to be increased to 384K for some >> platforms. >> My fix for JDK-8081770 >> https://bugs.openjdk.java.net/browse/JDK-8081770 moved the functionality >> from the testme.sh script to exeinvoke.c so the dependency for a >> local compiler could be removed. >> Because of this the stack size change needs to be applied to >> exeinvoke.c file instead of the testme.sh file. >> >> Please let me know if you have any questions or concerns. > > It took me a little bit to figure out how this failure started happening > in the first place. My guess is that your fix for JDK-8081770 made it > so that the test was now runnable on ARM64, where before it wouldn't > run because of the local compiler dependency. Now that a local compiler > is not needed, the original -Xss320k is discovered to be insufficient > on ARM64. Do I have all this right? > Yes, you have it right. > > Thumbs up pending a reply that shows you have done adequate testing on > this fix. > > Dan Thanks! Jerry > > >> >> Thanks, >> >> Jerry > From karen.kinnear at oracle.com Tue Jul 26 17:31:11 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 26 Jul 2016 13:31:11 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: References: Message-ID: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> Coleen, Thank you for the reminder on this review - > On Jul 21, 2016, at 6:45 PM, Coleen Phillimore wrote: > > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html > > +// Handles unsafe_DefineAnonymousClass and redefineclasses > +// redefinedclasses do not add to the class hierarchy > > Can you change /redefineclasses/RedefineClasses/? We pattern match on this. Fixed. > > Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ Fixed the two additional blank lines - thank you for catching. > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html > > Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. Done. Made it private static for now. > > http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html > > Awesome! I'm glad you found this comment to remove. thanks to Frederic. > > Nobody's going to miss parsed_name. This is a nice change! I hoped you would like that :-) thanks for the review, Karen > > Thanks, > Coleen > > On 7/21/16 1:23 PM, Karen Kinnear wrote: >> Please review: >> https://bugs.openjdk.java.net/browse/JDK-8162340 >> >> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ >> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev >> >> When moving the check from resolve_from_stream to set_package, I removed >> the no longer need parsed_class (!) which I should have cleaned up when >> tightening the placeholder table cleanup years ago. >> >> Tests run: >> 1. updated VMAnonymousClass test >> 2. jcks >> 3. rbt hs-nightly-runtime linux-x64 in progress >> >> thanks, >> Karen >> >> > From coleen.phillimore at oracle.com Tue Jul 26 17:50:06 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jul 2016 13:50:06 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> References: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> Message-ID: <5f805e1a-6cb6-a58b-c13c-3d75176eda6c@oracle.com> Thanks! Coleen On 7/26/16 1:31 PM, Karen Kinnear wrote: > Coleen, > > Thank you for the reminder on this review - > >> On Jul 21, 2016, at 6:45 PM, Coleen Phillimore wrote: >> >> >> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >> >> +// Handles unsafe_DefineAnonymousClass and redefineclasses >> +// redefinedclasses do not add to the class hierarchy >> >> Can you change /redefineclasses/RedefineClasses/? We pattern match on this. > Fixed. >> Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ > Fixed the two additional blank lines - thank you for catching. >> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. > Done. Made it private static for now. >> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html >> >> Awesome! I'm glad you found this comment to remove. > thanks to Frederic. >> Nobody's going to miss parsed_name. This is a nice change! > I hoped you would like that :-) > > thanks for the review, > Karen >> Thanks, >> Coleen >> >> On 7/21/16 1:23 PM, Karen Kinnear wrote: >>> Please review: >>> https://bugs.openjdk.java.net/browse/JDK-8162340 >>> >>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ >>> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev >>> >>> When moving the check from resolve_from_stream to set_package, I removed >>> the no longer need parsed_class (!) which I should have cleaned up when >>> tightening the placeholder table cleanup years ago. >>> >>> Tests run: >>> 1. updated VMAnonymousClass test >>> 2. jcks >>> 3. rbt hs-nightly-runtime linux-x64 in progress >>> >>> thanks, >>> Karen >>> >>> From david.holmes at oracle.com Tue Jul 26 20:21:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 06:21:10 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <01307e60-49bc-69ed-2b00-201b7978b284@oracle.com> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> Message-ID: <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> The patch for this used the wrong bug ID - 8161258 instead of 8161259. Not sure what I'm going to be able to do about that :( David ----- On 26/07/2016 11:12 AM, David Holmes wrote: > On 25/07/2016 3:01 PM, David Holmes wrote: >> This all looks good. Approval is now in place. Just waiting for final >> conformation this builds okay for Aarch64 folk. > > That confirmation was sent to compiler-dev so the changes have been pushed. > > David > >> Thanks, >> David >> >> On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> >>>> I see the typo was actually much bigger than I thought :) Presumably >>>> the >>> Well, I edited it some more ... this time I replaced the webrev >>> in-place, >>> webrev.05 is fixed now. >>> >>> I really should have an aarch64 machine :) >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 21. Juli 2016 12:00 >>>> To: Lindenmaier, Goetz ; Kim Barrett >>>> >>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>> >>>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> Copyright of register_definitions_x86.cpp is already fixed in hs-comp, >>>>> I'll skip it to avoid merges. >>>> >>>> This isn't going into hs-comp so I don't know when the two will >>>> collide. >>>> I would deal with it anyway - I can just apply the patch without >>>> committing, deal with any merges, and then commit as you. >>>> >>>>> I fixed the others. New webrevs, also with Coleens fixes: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ >>>> >>>> I see the typo was actually much bigger than I thought :) Presumably >>>> the >>>> INLCUDE typo caused it to be missed by a global search replace. >>>> >>>>> I also did another zero build configured as follows: >>>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- >>>> variants=zero >>>>> on linuxx86_64. >>>> >>>> Thanks. >>>> >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 21. Juli 2016 05:26 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>> newPfmIncl/webrev.04/ >>>>>>> >>>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >>>>>> CompileJvm.gmk >>>>>>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I >>>>>> documented >>>>>>> what I learned about the platform defines in macros.hpp. >>>>>> >>>>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) >>>>>> and >>>>>> the lingering _32 the only nit I have left is a handful of copyright >>>>>> updates: >>>>>> >>>>>> src/cpu/x86/vm/register_definitions_x86.cpp: >>>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >>>>>> src/share/vm/runtime/semaphore.hpp: >>>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >>>>>> src/cpu/ppc/vm/templateTable_ppc.hpp >>>>>> >>>>>> Then all we need is confirmation that all the open platforms that >>>>>> Oracle >>>>>> doesn't also build (aarch64 and Zero) build and run successfully >>>>>> after >>>>>> this change. >>>>>> >>>>>> I will sponsor this (in case that wasn't clear) but may have to >>>>>> delay it >>>>>> until after we sync up the hs forest with the CPU changes now in >>>>>> jdk9/dev. I will rebase and handle any merging if needed. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> OK, to get this through I will add >>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>> and revert this one and only place it needs to be used in the >>>>>>>> vmStructs_jvmci.cpp. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such >>>> cleanups >>>>>>>> should >>>>>>>>> not be in this change. >>>>>>>> >>>>>>>> I did not know they had a 64-bit C1 - interesting. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for doing the closed changes! >>>>>>>> >>>>>>>> You're welcome. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> that's great what you are saying and just the design I would >>>>>>>>>>> expect! >>>>>>>>>>>> We did not want to have to >>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit >>>> ARM" >>>>>> so >>>>>>>>>>>> we worked with the Open port to ensure that shared code >>>> guarded >>>>>> by >>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>>> identify >>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>>>>>> places >>>>>>>>>>>> that needed it. And sometimes we have to be careful and ensure >>>>>> that >>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>> >>>>>>>>>>> I think as a consequence the open AARCH port should define ARM, >>>>>> too. >>>>>>>>>> >>>>>>>>>> I would not want to do this and certainly not as part of this >>>>>>>>>> change. >>>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, >>>>>>>>>> but not >>>>>>>>>> right now, please. >>>>>>>>>> >>>>>>>>>>> I checked the occurrences and only see three places where this >>>> would >>>>>>>> have >>>>>>>>>>> an effect and would have to be fixed somehow: >>>>>>>>>>> >>>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>>>>>> [610] #if defined(AARCH64) && >>>>>>>>>>> !defined(ARM) >>>>>>>>>>> ==> Would this break the closed port if defined? >>>>>>>>>> >>>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 >>>>>>>>>> sources. >>>>>>>>>> >>>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was >>>> used) >>>>>>>>>>> >>>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>>>>>> load_item_force[253] #if !defined(ARM) && >>>>>>>>>>> !defined(E500V2) >>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>> >>>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>>>>>> [1154] #ifdef ARM >>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>> >>>>>>>>>> I don't think the open port has C1 so it would ignore the above >>>>>>>>>> files >>>>>>>>>> anyway. >>>>>>>>>> >>>>>>>>>>> All the cases below are pointless. >>>>>>>>>>> >>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>> defines, but >>>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>>> conditional >>>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>> I think it's quite misleading to have two defines that are 99% >>>>>> equivalent. >>>>>>>>>>> If we really need a special case here, you should define - >>>>>> DARM_CLOSED >>>>>>>>>>> or the like in your closed port. Such a name would make clear >>>> what's >>>>>> the >>>>>>>>>>> issue. At least, only your closed port has this problem. >>>>>>>>>> >>>>>>>>>> I really do not want to make any changes to this - ignoring the >>>> include >>>>>>>>>> macro changes everything we have is working perfectly fine just >>>>>>>>>> the >>>>>> way >>>>>>>>>> the defines are. So I don't want to see this change potentially >>>>>>>>>> break >>>>>>>>>> that through incidental changes. >>>>>>>>>> >>>>>>>>>> I do not see having the following is a big issue: >>>>>>>>>> >>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>> >>>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that define >>>>>> intend >>>>>>>> it to >>>>>>>>>> mean. It certainly is a lot better than interpreting what the >>>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the >>>>>>>> need to >>>>>>>>>> perform some of the changes as noted above. >>>>>>>>>> >>>>>>>>>> I'm preparing the review of the internal changes we need to >>>>>> accompany >>>>>>>> this. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These should not break the open port if ARM gets defined, or can >>>> be >>>>>>>> fixed >>>>>>>>>> easily. >>>>>>>>>>> --------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>> print[1519] #elif defined(ARM) >>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>> >>>>>>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>> >>>>>>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>>>>>> >>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == >>>>>>>>>>> cpu_register) >>>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == >>>>>>>>>>> cpu_register) >>>>>>>>>>> ==> Just an assertion. Will just relax the check if defined >>>>>>>>>>> in open >>>>>>>> AARCH64. >>>>>>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>>>>>> [70] #if defined(ARM) || >>>>>>>>>>> defined(AARCH64) || >>>>>>>>>> defined(PPC64) >>>>>>>>>>> ==> Fine: || >>>>>>>>>>> >>>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>>>>>> [447] #if defined(SPARC) || >>>>>>>>>>> defined(ARM) || >>>>>>>>>> defined(PPC) || defined(AARCH64) >>>>>>>>>>> [537] #if defined(X86) || >>>>>>>>>>> defined(ARM) || >>>>>>>>>> defined(AARCH64) >>>>>>>>>>> ==> Fine: || >>>>>>>>>>> >>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>>>>>> defined[162] #if defined(IA32) || >>>>>>>>>>> defined(AMD64) || >>>>>>>>>> defined(ARM) >>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>>>>>> [1358] #if defined(IA32) || >>>>>>>>>>> defined(AMD64) || >>>>>>>>>> defined(ARM) >>>>>>>>>>> ==> Just defines a method which would be unused, should be fine. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These are in code not used in the open AARCH64 port: >>>>>>>>>>> -------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>> [215] #elif defined(ARM) >>>>>>>>>>> >>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>>>>>> [434] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, >>>>>>>>>>> __powerpc__, >>>>>> ARM, >>>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>>>>>> >>>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, >>>>>>>>>>> __powerpc__, >>>>>> ARM, >>>>>>>>>> ARM >>>>>>>>>>> >>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>> store[164] #if !defined(ARM) && >>>>>>>>>>> !defined(M68K) >>>>>>>>>>> store_ptr[171] #if !defined(ARM) && >>>>>>>>>>> !defined(M68K) >>>>>>>>>>> add[178] #ifdef ARM >>>>>>>>>>> add_ptr[190] #ifdef ARM >>>>>>>>>>> xchg[230] #ifdef ARM >>>>>>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>>>>>> cmpxchg[275] #ifdef ARM >>>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>> add[172] #ifdef ARM >>>>>>>>>>> add_ptr[184] #ifdef ARM >>>>>>>>>>> xchg[224] #ifdef ARM >>>>>>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>>>>>> cmpxchg[269] #ifdef ARM >>>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>> Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>> files. >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>>>>>>>> (Parisc is gone, puh!). >>>>>>>>>>>>> We basically patch all the shared changes onto the sources >>>>>>>>>>>>> after >>>>>>>>>>>>> getting them via our licensee channel. >>>>>>>>>>>>> I think you should fix your closed port not to re-use the >>>>>>>>>>>>> names of >>>>>> the >>>>>>>>>>>>> main openJdk platforms! >>>>>>>>>>>> >>>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to >>>>>> have >>>>>>>> to >>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit >>>> ARM" >>>>>> so >>>>>>>>>>>> we worked with the Open port to ensure that shared code >>>> guarded >>>>>> by >>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>>> identify >>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of >>>>>>>> places >>>>>>>>>>>> that needed it. And sometimes we have to be careful and ensure >>>>>> that >>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>> >>>>>>>>>>>> This has all been working quite nicely, as the include guards >>>>>>>>>>>> used, >>>> for >>>>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - >>>> which >>>>>>>> are >>>>>>>>>>>> never >>>>>>>>>>>> defined at the same time (derived from >>>>>>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>>>>>> But >>>>>>>>>>>> the >>>>>>>>>>>> current changes remove those unique defines and, before the >>>>>>>> HEADER_H >>>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >>>>>>>> include >>>>>>>>>>>> guards, and that doesn't work as they are not mutually >>>>>>>>>>>> exclusive. >>>>>>>>>>>> >>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>> defines, but >>>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>>> conditional >>>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> I have no idea what hardware is addressed by your closed >>>>>>>>>>>>> ports, >>>>>>>>>>>>> nor how you merge sources. >>>>>>>>>>>>> Is there also a port that sets >>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>> -DARM >>>>>>>>>>>>> -DARM32 >>>>>>>>>>>>> ? >>>>>>>>>>>>> >>>>>>>>>>>>> To fix this either you define >>>>>>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>>>>>> #define ARM64 >>>>>>>>>>>>> #endif >>>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>>>>>> Then you replace all >>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>> by >>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>> by >>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>>>>>> >>>>>>>>>>>>> For ppc, when we did the port we knew (and that's all we knew) >>>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these macros >>>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for >>>>>>>> LP64/!LP64 >>>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed >>>>>>>>>>>>> port >>>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both >>>>>>>> (PPC). >>>>>>>>>>>>> >>>>>>>>>>>>> But I don't think it is necessary to do any further changes >>>>>>>>>>>>> now, >>>>>>>> assuming >>>>>>>>>>>>> my change works for you as I adapted it. So we're all set I >>>>>>>>>>>>> guess! >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>> Barrett >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >>>>>> kind >>>>>>>> of >>>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>>> Aarch64 >>>>>>>>>> port >>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>>> Open >>>>>>>> port >>>>>>>>>>>> use >>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>>> just >>>>>>>>>> something >>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? >>>> You >>>>>>>> have >>>>>>>>>> to >>>>>>>>>>>>>>> check every AARCH change by RedHat against your closed >>>> port? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The sources for the two ports are distinct so the only >>>>>>>>>>>>>> place we >>>>>> have >>>>>>>> to >>>>>>>>>>>>>> have a convention is in shared code that has CPU specific >>>>>>>>>>>>>> stuff >>>> and >>>>>> in >>>>>>>>>>>>>> the build files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>> >>>>>>>>>>>>>> the closed port sets >>>>>>>>>>>>>> >>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>> >>>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes >>>>>>>>>>>>>> them. >>>>>>>>>>>> Whenever >>>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was >>>>>> referring >>>>>>>> to >>>>>>>>>>>> our >>>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open >>>>>> Aarch64 >>>>>>>>>> port. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We need to keep a clear distinction. Using the combination of >>>>>>>> AARCH64 >>>>>>>>>>>>>> and ARM is not so clear. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You could easily have similar issues with other port groups >>>>>>>>>>>>>> - eg >>>>>> ppc64 >>>>>>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up >>>> recently, >>>>>>>> and >>>>>>>>>>>>>>> before that it sure was equivalent. And it still is the >>>>>>>>>>>>>>> case for >>>>>>>> openJDK. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Below output is grepped out of the >>>> make//platform_ >>>>>>>> files >>>>>>>>>> in >>>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined >>>>>> twice. >>>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>> D_GNU_SOURCE >>>>>>>> - >>>>>>>>>>>>>> DAMD64 >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>> D_GNU_SOURCE >>>>>>>> - >>>>>>>>>>>> DIA32 >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >>>>>>>> DCC_INTERP >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >>>> DCC_INTERP - >>>>>>>>>> DZERO - >>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>>>> DAMD64 >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>> DIA32 >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>> runtime- >>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any >>>> further >>>>>>>>>> issues, >>>>>>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen >>>> in >>>>>> this >>>>>>>>>> new >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>>>>>>>> at the same time. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This >>>>>> kind >>>>>>>> of >>>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>>> Aarch64 >>>>>>>>>> port >>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>>> Open >>>>>>>> port >>>>>>>>>>>> use >>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>>> just >>>>>>>>>> something >>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>> Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>> files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should >>>> be >>>>>>>> fixed >>>>>>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just >>>>>>>>>>>>>>>>>>> that. >>>> :) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value >>>>>> for >>>>>>>> the >>>>>>>>>>>> ifdef >>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change that >>>>>> value >>>>>>>> to >>>>>>>>>>>>>> match >>>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to >>>> other >>>>>>>>>>>> problems >>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>> we also need that value the way it is currently defined. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H >>>> macro. >>>>>> In >>>>>>>>>>>> general >>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our >>>>>> case >>>>>>>>>> ARM >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In >>>> contrast >>>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen >>>> to >>>>>>>>>>>> represent >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>> ; >>>>>>>> Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>> hotspot- >>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>>> appends >>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>> CPU_HEADER_H, >>>>>>>>>> that >>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >>>>>> used >>>>>>>>>> only >>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>> should do >>>> it >>>>>> to >>>>>>>> get >>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>>> need >>>>>> not >>>>>>>>>> be >>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>>> needs >>>>>> to >>>>>>>> be >>>>>>>>>> an >>>>>>>>>>>> if- >>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in >>>>>>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>> in the same statement as the >>>> INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from >>>> the >>>>>>>> closed >>>>>>>>>>>> part >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So >>>> we >>>>>> get >>>>>>>>>> both >>>>>>>>>>>>>>>> defined >>>>>>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >>>>>>>> understand >>>>>>>>>>>> what >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to >>>>>> be, >>>>>>>> as >>>>>>>>>> we >>>>>>>>>>>>>> are >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the >>>>>>>>>>>>>>>>>>>>> current >>>>>>>> problem, >>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>> ; >>>>>>>>>> Kim >>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>> hotspot- >>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>> platform >>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more >>>>>>>>>>>>>>>>>>>>>>>> detail! >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>> ; >>>>>>>>>>>> Kim >>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>> hotspot- >>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>> platform >>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz >>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications >>>> and >>>>>>>>>>>> comments >>>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch >>>>>> directory, >>>>>>>> but >>>>>>>>>> I >>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files. >>>>>>>> (Sorry I >>>>>>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what >>>> needs >>>>>> to >>>>>>>>>> be >>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this >>>> :).) >>>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory >>>> that >>>>>> has >>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to >>>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >>>>>>>> header >>>>>>>>>>>> files if >>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that >>>>>>>>>>>>>>>>>>>>>>>>> dispatches >>>>>>>>>> internally >>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did >>>>>>>>>>>>>>>>>>>>>>>> not >>>>>> hold: >>>>>>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was >>>> a >>>>>>>>>> common >>>>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to >>>> avoid >>>>>> this >>>>>>>>>> kind >>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >>>>>> TARGET_SO... >>>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be >>>> moved >>>>>> to >>>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >>>>>>>> elided >>>>>>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is >>>> the >>>>>>>>>>>> umbrella >>>>>>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>>> appends >>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>> CPU_HEADER_H, >>>>>>>>>> that >>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be >>>>>> used >>>>>>>>>> only >>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>> should do >>>> it >>>>>> to >>>>>>>> get >>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>>> need >>>>>> not >>>>>>>>>> be >>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>>> needs >>>>>> to >>>>>>>> be >>>>>>>>>> an >>>>>>>>>>>> if- >>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of >>>> WINDOWS? Is >>>>>>>> that >>>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>>>>>>>> WINDOWS >>>>>>>>>>>> in >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is >>>>>> defining >>>>>>>> - >>>>>>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, >>>>>> but >>>>>>>> not >>>>>>>>>> in >>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >>>>>>>> unused >>>>>>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty >>>> file. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> ; >>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>>>> hotspot- >>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>>> platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz >>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's >>>>>> working >>>>>>>> on >>>>>>>>>> all >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the >>>>>>>> macros >>>>>>>>>> and >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>>>>>>>> construction >>>>>>>>>>>>>> are >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >>>>>> macros.hpp. >>>>>>>> But >>>>>>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and >>>> uses >>>>>>>> the >>>>>>>>>>>> very >>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could >>>>>> include >>>>>>>>>> that >>>>>>>>>>>> in >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as >>>>>> fine >>>>>>>>>> with >>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is >>>> that >>>>>>>> the >>>>>>>>>>>> linux=1 >>>>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros >>>> should >>>>>> be >>>>>>>>>>>> upper >>>>>>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>>>>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; >>>>>> hotspot- >>>>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>>> including >>>>>>>>>>>> platform >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, >>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these >>>> macros >>>>>> are >>>>>>>>>> only >>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody >>>>>> needs >>>>>>>> to >>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp >>>>>> and >>>>>>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to >>>>>>>> spend >>>>>>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted >>>> my >>>>>>>>>> current >>>>>>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to >>>> do >>>>>> is >>>>>>>>>> adding >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the >>>> includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>>>>>>>> proposed >>>>>>>>>>>> in >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email >>>>>> thread >>>>>>>> for >>>>>>>>>>>> me; it >>>>>>>>>>>>>>>> looks >>>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- >>>> compiler- >>>>>> dev >>>>>>>> but >>>>>>>>>>>> not >>>>>>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list >>>>>> this >>>>>>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details. >>>> I've >>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can >>>>>> wait >>>>>>>>>> until >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> --- >>>>>> --- >>>>>>>> ---- >>>>>>>>>> --- >>>>>>>>>>>> ---- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround >>>> existing >>>>>>>>>> #defines >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so >>>> far: >>>>>>>>>> linux=1, >>>>>>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the >>>>>> leading >>>>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>>>>>> >>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the >>>>>> values. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written >>>> as >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >>>>>>>> instead >>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) >>>> are >>>>>>>>>> defined, >>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>>>>>>>> underscore >>>>>>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >>>>>>>> pattern >>>>>>>>>>>> for >>>>>>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use >>>>>> uppercase >>>>>>>> for >>>>>>>>>>>> the >>>>>>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> --- >>>>>> --- >>>>>>>> ---- >>>>>>>>>> --- >>>>>>>>>>>> ---- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> From coleen.phillimore at oracle.com Tue Jul 26 21:04:15 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jul 2016 17:04:15 -0400 Subject: RFR: JDK-8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134 In-Reply-To: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> References: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> Message-ID: This analysis and fix look good. Coleen On 7/25/16 7:04 PM, Jiangli Zhou wrote: > Please review the following webrev for JDK-8156959 fix. > > http://cr.openjdk.java.net/~jiangli/8156959/webrev.00/ > > The SensorInfo::has_pending_requests() is not thread safe. It tests '_pending_trigger_count > 0 || _pending_clear_count > 0?. In rare cases, there is a race condition in which the check done by the service thread might return ?false? incorrectly while _pending_trigger_count is incremented to 1 and _pending_clear_count is reset to 0 by other thread. In that case, the 'assert(has_pending_requests(), "Must have pending request?)? in SensorInfo::process_pending_requests() becomes invalid. The fix removes the invalid assert. > > As _pending_trigger_count can only be decremented by the service thread and all other threads can only increment the _pending_trigger_count, the race condition issue of SensorInfo::has_pending_requests() is harmless in other usages. If the service thread fails to catch the pending request (when has_pending_requests() returns false incorrectly), it can catch the it in the next iteration. Please see the JDK-8156959 for detailed analysis. > > Test: JPRT and RBT hotspot_all. > > Thanks, > Jiangli > From jiangli.zhou at oracle.com Tue Jul 26 21:13:43 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 26 Jul 2016 14:13:43 -0700 Subject: RFR: JDK-8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134 In-Reply-To: References: <23D9BD11-3736-42D0-BA91-DAB029315FA0@oracle.com> Message-ID: <272D329A-5394-4DB7-9086-06037AAB30CD@oracle.com> Hi Coleen, Thanks for the review! Jiangli > On Jul 26, 2016, at 2:04 PM, Coleen Phillimore wrote: > > > This analysis and fix look good. > Coleen > > On 7/25/16 7:04 PM, Jiangli Zhou wrote: >> Please review the following webrev for JDK-8156959 fix. >> >> http://cr.openjdk.java.net/~jiangli/8156959/webrev.00/ >> >> The SensorInfo::has_pending_requests() is not thread safe. It tests '_pending_trigger_count > 0 || _pending_clear_count > 0?. In rare cases, there is a race condition in which the check done by the service thread might return ?false? incorrectly while _pending_trigger_count is incremented to 1 and _pending_clear_count is reset to 0 by other thread. In that case, the 'assert(has_pending_requests(), "Must have pending request?)? in SensorInfo::process_pending_requests() becomes invalid. The fix removes the invalid assert. >> >> As _pending_trigger_count can only be decremented by the service thread and all other threads can only increment the _pending_trigger_count, the race condition issue of SensorInfo::has_pending_requests() is harmless in other usages. If the service thread fails to catch the pending request (when has_pending_requests() returns false incorrectly), it can catch the it in the next iteration. Please see the JDK-8156959 for detailed analysis. >> >> Test: JPRT and RBT hotspot_all. >> >> Thanks, >> Jiangli >> > From daniel.daugherty at oracle.com Tue Jul 26 21:38:03 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Jul 2016 15:38:03 -0600 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <5cb2edcdc30c462696f8fa49bfb5f6d1@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> Message-ID: I've made some manual updates to both bugs and will keep an eye on JDK-8161258. As it goes through it's phases I'll try to make the same updates to JDK-8161259. Dan On 7/26/16 2:21 PM, David Holmes wrote: > The patch for this used the wrong bug ID - 8161258 instead of 8161259. > > Not sure what I'm going to be able to do about that :( > > David > ----- > > On 26/07/2016 11:12 AM, David Holmes wrote: >> On 25/07/2016 3:01 PM, David Holmes wrote: >>> This all looks good. Approval is now in place. Just waiting for final >>> conformation this builds okay for Aarch64 folk. >> >> That confirmation was sent to compiler-dev so the changes have been >> pushed. >> >> David >> >>> Thanks, >>> David >>> >>> On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> >>>>> I see the typo was actually much bigger than I thought :) Presumably >>>>> the >>>> Well, I edited it some more ... this time I replaced the webrev >>>> in-place, >>>> webrev.05 is fixed now. >>>> >>>> I really should have an aarch64 machine :) >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Donnerstag, 21. Juli 2016 12:00 >>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>> >>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>> >>>>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> Copyright of register_definitions_x86.cpp is already fixed in >>>>>> hs-comp, >>>>>> I'll skip it to avoid merges. >>>>> >>>>> This isn't going into hs-comp so I don't know when the two will >>>>> collide. >>>>> I would deal with it anyway - I can just apply the patch without >>>>> committing, deal with any merges, and then commit as you. >>>>> >>>>>> I fixed the others. New webrevs, also with Coleens fixes: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ >>>>> >>>>> I see the typo was actually much bigger than I thought :) Presumably >>>>> the >>>>> INLCUDE typo caused it to be missed by a global search replace. >>>>> >>>>>> I also did another zero build configured as follows: >>>>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- >>>>> variants=zero >>>>>> on linuxx86_64. >>>>> >>>>> Thanks. >>>>> >>>>> David >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Donnerstag, 21. Juli 2016 05:26 >>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>> >>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>> >>>>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>> newPfmIncl/webrev.04/ >>>>>>>> >>>>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >>>>>>> CompileJvm.gmk >>>>>>>> and reverts the change to the aarch define in >>>>>>>> vmStructs_jvmci.cpp. I >>>>>>> documented >>>>>>>> what I learned about the platform defines in macros.hpp. >>>>>>> >>>>>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) >>>>>>> and >>>>>>> the lingering _32 the only nit I have left is a handful of >>>>>>> copyright >>>>>>> updates: >>>>>>> >>>>>>> src/cpu/x86/vm/register_definitions_x86.cpp: >>>>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >>>>>>> src/share/vm/runtime/semaphore.hpp: >>>>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >>>>>>> src/cpu/ppc/vm/templateTable_ppc.hpp >>>>>>> >>>>>>> Then all we need is confirmation that all the open platforms that >>>>>>> Oracle >>>>>>> doesn't also build (aarch64 and Zero) build and run successfully >>>>>>> after >>>>>>> this change. >>>>>>> >>>>>>> I will sponsor this (in case that wasn't clear) but may have to >>>>>>> delay it >>>>>>> until after we sync up the hs forest with the CPU changes now in >>>>>>> jdk9/dev. I will rebase and handle any merging if needed. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>> >>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>> >>>>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> OK, to get this through I will add >>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>> and revert this one and only place it needs to be used in the >>>>>>>>> vmStructs_jvmci.cpp. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such >>>>> cleanups >>>>>>>>> should >>>>>>>>>> not be in this change. >>>>>>>>> >>>>>>>>> I did not know they had a 64-bit C1 - interesting. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for doing the closed changes! >>>>>>>>> >>>>>>>>> You're welcome. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>>>> >>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>> files. >>>>>>>>>>> >>>>>>>>>>> Hi Goetz, >>>>>>>>>>> >>>>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> that's great what you are saying and just the design I would >>>>>>>>>>>> expect! >>>>>>>>>>>>> We did not want to have to >>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for >>>>>>>>>>>>> "64-bit >>>>> ARM" >>>>>>> so >>>>>>>>>>>>> we worked with the Open port to ensure that shared code >>>>> guarded >>>>>>> by >>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>>>> identify >>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a >>>>>>>>>>>>> handful of >>>>>>>>> places >>>>>>>>>>>>> that needed it. And sometimes we have to be careful and >>>>>>>>>>>>> ensure >>>>>>> that >>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>> >>>>>>>>>>>> I think as a consequence the open AARCH port should define >>>>>>>>>>>> ARM, >>>>>>> too. >>>>>>>>>>> >>>>>>>>>>> I would not want to do this and certainly not as part of this >>>>>>>>>>> change. >>>>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, >>>>>>>>>>> but not >>>>>>>>>>> right now, please. >>>>>>>>>>> >>>>>>>>>>>> I checked the occurrences and only see three places where this >>>>> would >>>>>>>>> have >>>>>>>>>>>> an effect and would have to be fixed somehow: >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>>>>>>> [610] #if defined(AARCH64) && >>>>>>>>>>>> !defined(ARM) >>>>>>>>>>>> ==> Would this break the closed port if defined? >>>>>>>>>>> >>>>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 >>>>>>>>>>> sources. >>>>>>>>>>> >>>>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was >>>>> used) >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>>>>>>> load_item_force[253] #if !defined(ARM) && >>>>>>>>>>>> !defined(E500V2) >>>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>>>>>>> [1154] #ifdef ARM >>>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>> >>>>>>>>>>> I don't think the open port has C1 so it would ignore the above >>>>>>>>>>> files >>>>>>>>>>> anyway. >>>>>>>>>>> >>>>>>>>>>>> All the cases below are pointless. >>>>>>>>>>>> >>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>>> defines, but >>>>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>>>> conditional >>>>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>>> I think it's quite misleading to have two defines that are 99% >>>>>>> equivalent. >>>>>>>>>>>> If we really need a special case here, you should define - >>>>>>> DARM_CLOSED >>>>>>>>>>>> or the like in your closed port. Such a name would make clear >>>>> what's >>>>>>> the >>>>>>>>>>>> issue. At least, only your closed port has this problem. >>>>>>>>>>> >>>>>>>>>>> I really do not want to make any changes to this - ignoring the >>>>> include >>>>>>>>>>> macro changes everything we have is working perfectly fine just >>>>>>>>>>> the >>>>>>> way >>>>>>>>>>> the defines are. So I don't want to see this change potentially >>>>>>>>>>> break >>>>>>>>>>> that through incidental changes. >>>>>>>>>>> >>>>>>>>>>> I do not see having the following is a big issue: >>>>>>>>>>> >>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>> >>>>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that define >>>>>>> intend >>>>>>>>> it to >>>>>>>>>>> mean. It certainly is a lot better than interpreting what the >>>>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the >>>>>>>>> need to >>>>>>>>>>> perform some of the changes as noted above. >>>>>>>>>>> >>>>>>>>>>> I'm preparing the review of the internal changes we need to >>>>>>> accompany >>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These should not break the open port if ARM gets defined, >>>>>>>>>>>> or can >>>>> be >>>>>>>>> fixed >>>>>>>>>>> easily. >>>>>>>>>>>> --------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>>> print[1519] #elif defined(ARM) >>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>>> >>>>>>>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == >>>>>>>>>>>> cpu_register) >>>>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == >>>>>>>>>>>> cpu_register) >>>>>>>>>>>> ==> Just an assertion. Will just relax the check if defined >>>>>>>>>>>> in open >>>>>>>>> AARCH64. >>>>>>>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>>>>>>> [70] #if defined(ARM) || >>>>>>>>>>>> defined(AARCH64) || >>>>>>>>>>> defined(PPC64) >>>>>>>>>>>> ==> Fine: || >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>>>>>>> [447] #if defined(SPARC) || >>>>>>>>>>>> defined(ARM) || >>>>>>>>>>> defined(PPC) || defined(AARCH64) >>>>>>>>>>>> [537] #if defined(X86) || >>>>>>>>>>>> defined(ARM) || >>>>>>>>>>> defined(AARCH64) >>>>>>>>>>>> ==> Fine: || >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>>>>>>> defined[162] #if defined(IA32) || >>>>>>>>>>>> defined(AMD64) || >>>>>>>>>>> defined(ARM) >>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>>>>>>> [1358] #if defined(IA32) || >>>>>>>>>>>> defined(AMD64) || >>>>>>>>>>> defined(ARM) >>>>>>>>>>>> ==> Just defines a method which would be unused, should be >>>>>>>>>>>> fine. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These are in code not used in the open AARCH64 port: >>>>>>>>>>>> -------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>>> [215] #elif defined(ARM) >>>>>>>>>>>> >>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>>>>>>> [434] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, >>>>>>>>>>>> __powerpc__, >>>>>>> ARM, >>>>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>>>>>>> >>>>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, >>>>>>>>>>>> __powerpc__, >>>>>>> ARM, >>>>>>>>>>> ARM >>>>>>>>>>>> >>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>>> store[164] #if !defined(ARM) && >>>>>>>>>>>> !defined(M68K) >>>>>>>>>>>> store_ptr[171] #if !defined(ARM) && >>>>>>>>>>>> !defined(M68K) >>>>>>>>>>>> add[178] #ifdef ARM >>>>>>>>>>>> add_ptr[190] #ifdef ARM >>>>>>>>>>>> xchg[230] #ifdef ARM >>>>>>>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>>>>>>> cmpxchg[275] #ifdef ARM >>>>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>>> add[172] #ifdef ARM >>>>>>>>>>>> add_ptr[184] #ifdef ARM >>>>>>>>>>>> xchg[224] #ifdef ARM >>>>>>>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>>>>>>> cmpxchg[269] #ifdef ARM >>>>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>> Barrett >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>> files. >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>>>>>>>>> (Parisc is gone, puh!). >>>>>>>>>>>>>> We basically patch all the shared changes onto the sources >>>>>>>>>>>>>> after >>>>>>>>>>>>>> getting them via our licensee channel. >>>>>>>>>>>>>> I think you should fix your closed port not to re-use the >>>>>>>>>>>>>> names of >>>>>>> the >>>>>>>>>>>>>> main openJdk platforms! >>>>>>>>>>>>> >>>>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to >>>>>>> have >>>>>>>>> to >>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for >>>>>>>>>>>>> "64-bit >>>>> ARM" >>>>>>> so >>>>>>>>>>>>> we worked with the Open port to ensure that shared code >>>>> guarded >>>>>>> by >>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>>>> identify >>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a >>>>>>>>>>>>> handful of >>>>>>>>> places >>>>>>>>>>>>> that needed it. And sometimes we have to be careful and >>>>>>>>>>>>> ensure >>>>>>> that >>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>>> >>>>>>>>>>>>> This has all been working quite nicely, as the include guards >>>>>>>>>>>>> used, >>>>> for >>>>>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - >>>>> which >>>>>>>>> are >>>>>>>>>>>>> never >>>>>>>>>>>>> defined at the same time (derived from >>>>>>>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>>>>>>> But >>>>>>>>>>>>> the >>>>>>>>>>>>> current changes remove those unique defines and, before the >>>>>>>>> HEADER_H >>>>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >>>>>>>>> include >>>>>>>>>>>>> guards, and that doesn't work as they are not mutually >>>>>>>>>>>>> exclusive. >>>>>>>>>>>>> >>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>>> defines, but >>>>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>>>> conditional >>>>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> I have no idea what hardware is addressed by your closed >>>>>>>>>>>>>> ports, >>>>>>>>>>>>>> nor how you merge sources. >>>>>>>>>>>>>> Is there also a port that sets >>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>> -DARM32 >>>>>>>>>>>>>> ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> To fix this either you define >>>>>>>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>>>>>>> #define ARM64 >>>>>>>>>>>>>> #endif >>>>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>>>>>>> Then you replace all >>>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>>> by >>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>>> by >>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>>>>>>> >>>>>>>>>>>>>> For ppc, when we did the port we knew (and that's all we >>>>>>>>>>>>>> knew) >>>>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these >>>>>>>>>>>>>> macros >>>>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for >>>>>>>>> LP64/!LP64 >>>>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed >>>>>>>>>>>>>> port >>>>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for >>>>>>>>>>>>>> both >>>>>>>>> (PPC). >>>>>>>>>>>>>> >>>>>>>>>>>>>> But I don't think it is necessary to do any further changes >>>>>>>>>>>>>> now, >>>>>>>>> assuming >>>>>>>>>>>>>> my change works for you as I adapted it. So we're all set I >>>>>>>>>>>>>> guess! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>>> Barrett >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. >>>>>>>>>>>>>>>>> This >>>>>>> kind >>>>>>>>> of >>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>>>> Aarch64 >>>>>>>>>>> port >>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>>>> Open >>>>>>>>> port >>>>>>>>>>>>> use >>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>>>> just >>>>>>>>>>> something >>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? >>>>> You >>>>>>>>> have >>>>>>>>>>> to >>>>>>>>>>>>>>>> check every AARCH change by RedHat against your closed >>>>> port? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The sources for the two ports are distinct so the only >>>>>>>>>>>>>>> place we >>>>>>> have >>>>>>>>> to >>>>>>>>>>>>>>> have a convention is in shared code that has CPU specific >>>>>>>>>>>>>>> stuff >>>>> and >>>>>>> in >>>>>>>>>>>>>>> the build files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the closed port sets >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes >>>>>>>>>>>>>>> them. >>>>>>>>>>>>> Whenever >>>>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was >>>>>>> referring >>>>>>>>> to >>>>>>>>>>>>> our >>>>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open >>>>>>> Aarch64 >>>>>>>>>>> port. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We need to keep a clear distinction. Using the >>>>>>>>>>>>>>> combination of >>>>>>>>> AARCH64 >>>>>>>>>>>>>>> and ARM is not so clear. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You could easily have similar issues with other port groups >>>>>>>>>>>>>>> - eg >>>>>>> ppc64 >>>>>>>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up >>>>> recently, >>>>>>>>> and >>>>>>>>>>>>>>>> before that it sure was equivalent. And it still is the >>>>>>>>>>>>>>>> case for >>>>>>>>> openJDK. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Below output is grepped out of the >>>>> make//platform_ >>>>>>>>> files >>>>>>>>>>> in >>>>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined >>>>>>> twice. >>>>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>>> D_GNU_SOURCE >>>>>>>>> - >>>>>>>>>>>>>>> DAMD64 >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>>> D_GNU_SOURCE >>>>>>>>> - >>>>>>>>>>>>> DIA32 >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >>>>>>>>> DCC_INTERP >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >>>>> DCC_INTERP - >>>>>>>>>>> DZERO - >>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>>>>> DAMD64 >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>>> DIA32 >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>>>>> Barrett >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>> runtime- >>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any >>>>> further >>>>>>>>>>> issues, >>>>>>>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen >>>>> in >>>>>>> this >>>>>>>>>>> new >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>>>>>>>>> at the same time. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. >>>>>>>>>>>>>>>>> This >>>>>>> kind >>>>>>>>> of >>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>>>> Aarch64 >>>>>>>>>>> port >>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>>>> Open >>>>>>>>> port >>>>>>>>>>>>> use >>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>>>> just >>>>>>>>>>> something >>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>>> Kim >>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>>> runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>>>>>>>>>>>> platform >>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should >>>>> be >>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just >>>>>>>>>>>>>>>>>>>> that. >>>>> :) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value >>>>>>> for >>>>>>>>> the >>>>>>>>>>>>> ifdef >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change >>>>>>>>>>>>>>>>>>>> that >>>>>>> value >>>>>>>>> to >>>>>>>>>>>>>>> match >>>>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to >>>>> other >>>>>>>>>>>>> problems >>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>> we also need that value the way it is currently >>>>>>>>>>>>>>>>>>>> defined. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm >>>>>>>>>>>>>>>>>>>> fresher. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H >>>>> macro. >>>>>>> In >>>>>>>>>>>>> general >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. >>>>>>>>>>>>>>>>>>> In our >>>>>>> case >>>>>>>>>>> ARM >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In >>>>> contrast >>>>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen >>>>> to >>>>>>>>>>>>> represent >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>> ; >>>>>>>>> Kim >>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>> hotspot- >>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>> platform >>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>>>> appends >>>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>>> CPU_HEADER_H, >>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each >>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>> used >>>>>>>>>>> only >>>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>>> should do >>>>> it >>>>>>> to >>>>>>>>> get >>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>>>> need >>>>>>> not >>>>>>>>>>> be >>>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>>>> needs >>>>>>> to >>>>>>>>> be >>>>>>>>>>> an >>>>>>>>>>>>> if- >>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are >>>>>>>>>>>>>>>>>>>>>>> set in >>>>>>>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>> in the same statement as the >>>>> INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from >>>>> the >>>>>>>>> closed >>>>>>>>>>>>> part >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So >>>>> we >>>>>>> get >>>>>>>>>>> both >>>>>>>>>>>>>>>>> defined >>>>>>>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >>>>>>>>> understand >>>>>>>>>>>>> what >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to >>>>>>> be, >>>>>>>>> as >>>>>>>>>>> we >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the >>>>>>>>>>>>>>>>>>>>>> current >>>>>>>>> problem, >>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>> ; >>>>>>>>>>> Kim >>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>> hotspot- >>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>> platform >>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more >>>>>>>>>>>>>>>>>>>>>>>>> detail! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> ; >>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>>> hotspot- >>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>> platform >>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz >>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications >>>>> and >>>>>>>>>>>>> comments >>>>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch >>>>>>> directory, >>>>>>>>> but >>>>>>>>>>> I >>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated >>>>>>>>>>>>>>>>>>>>>>>>>> files. >>>>>>>>> (Sorry I >>>>>>>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what >>>>> needs >>>>>>> to >>>>>>>>>>> be >>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send >>>>>>>>>>>>>>>>>>>>>>>>>> this >>>>> :).) >>>>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a >>>>>>>>>>>>>>>>>>>>>>>>> directory >>>>> that >>>>>>> has >>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it >>>>>>>>>>>>>>>>>>>>>>>>> builds to >>>>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >>>>>>>>> header >>>>>>>>>>>>> files if >>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that >>>>>>>>>>>>>>>>>>>>>>>>>> dispatches >>>>>>>>>>> internally >>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did >>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>> hold: >>>>>>>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was >>>>> a >>>>>>>>>>> common >>>>>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to >>>>> avoid >>>>>>> this >>>>>>>>>>> kind >>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >>>>>>> TARGET_SO... >>>>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be >>>>> moved >>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >>>>>>>>> elided >>>>>>>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is >>>>> the >>>>>>>>>>>>> umbrella >>>>>>>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed >>>>>>>>>>>>>>>>>>>>>>>>> anyways. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>>>> appends >>>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>>> CPU_HEADER_H, >>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each >>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>> used >>>>>>>>>>> only >>>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>>> should do >>>>> it >>>>>>> to >>>>>>>>> get >>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>>>> need >>>>>>> not >>>>>>>>>>> be >>>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>>>> needs >>>>>>> to >>>>>>>>> be >>>>>>>>>>> an >>>>>>>>>>>>> if- >>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of >>>>> WINDOWS? Is >>>>>>>>> that >>>>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>>>>>>>>> WINDOWS >>>>>>>>>>>>> in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is >>>>>>> defining >>>>>>>>> - >>>>>>>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, >>>>>>> but >>>>>>>>> not >>>>>>>>>>> in >>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >>>>>>>>> unused >>>>>>>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty >>>>> file. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>> ; >>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>>>>> hotspot- >>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>>>>>>>>>>>>>>>>>>>>>>>>>>> including >>>>>>>>>>> platform >>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz >>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's >>>>>>> working >>>>>>>>> on >>>>>>>>>>> all >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>> macros >>>>>>>>>>> and >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>>>>>>>>> construction >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >>>>>>> macros.hpp. >>>>>>>>> But >>>>>>>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and >>>>> uses >>>>>>>>> the >>>>>>>>>>>>> very >>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could >>>>>>> include >>>>>>>>>>> that >>>>>>>>>>>>> in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> am as >>>>>>> fine >>>>>>>>>>> with >>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is >>>>> that >>>>>>>>> the >>>>>>>>>>>>> linux=1 >>>>>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros >>>>> should >>>>>>> be >>>>>>>>>>>>> upper >>>>>>>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>>>>>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; >>>>>>> hotspot- >>>>>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>>>> including >>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, >>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these >>>>> macros >>>>>>> are >>>>>>>>>>> only >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody >>>>>>> needs >>>>>>>>> to >>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes.hpp >>>>>>> and >>>>>>>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>> spend >>>>>>>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted >>>>> my >>>>>>>>>>> current >>>>>>>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to >>>>> do >>>>>>> is >>>>>>>>>>> adding >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the >>>>> includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>>>>>>>>> proposed >>>>>>>>>>>>> in >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email >>>>>>> thread >>>>>>>>> for >>>>>>>>>>>>> me; it >>>>>>>>>>>>>>>>> looks >>>>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- >>>>> compiler- >>>>>>> dev >>>>>>>>> but >>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list >>>>>>> this >>>>>>>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details. >>>>> I've >>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>> wait >>>>>>>>>>> until >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> --- >>>>>>> --- >>>>>>>>> ---- >>>>>>>>>>> --- >>>>>>>>>>>>> ---- >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround >>>>> existing >>>>>>>>>>> #defines >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so >>>>> far: >>>>>>>>>>> linux=1, >>>>>>>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the >>>>>>> leading >>>>>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the >>>>>>> values. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written >>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >>>>>>>>> instead >>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) >>>>> are >>>>>>>>>>> defined, >>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >>>>>>>>> pattern >>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use >>>>>>> uppercase >>>>>>>>> for >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> --- >>>>>>> --- >>>>>>>>> ---- >>>>>>>>>>> --- >>>>>>>>>>>>> ---- >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> From karen.kinnear at oracle.com Tue Jul 26 22:18:09 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 26 Jul 2016 18:18:09 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <5f805e1a-6cb6-a58b-c13c-3d75176eda6c@oracle.com> References: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> <5f805e1a-6cb6-a58b-c13c-3d75176eda6c@oracle.com> Message-ID: <3218ED6D-4B9C-4C74-83A6-D9CD2DB88494@oracle.com> I updated the web rev after all - with Coleen?s suggested changes and shortened new comment lines. http://cr.openjdk.java.net/~acorn/8162340.hs.3/webrev/ I will push once I hear from David. thanks all, Karen > On Jul 26, 2016, at 1:50 PM, Coleen Phillimore wrote: > > > Thanks! > Coleen > > On 7/26/16 1:31 PM, Karen Kinnear wrote: >> Coleen, >> >> Thank you for the reminder on this review - >> >>> On Jul 21, 2016, at 6:45 PM, Coleen Phillimore wrote: >>> >>> >>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>> >>> +// Handles unsafe_DefineAnonymousClass and redefineclasses >>> +// redefinedclasses do not add to the class hierarchy >>> >>> Can you change /redefineclasses/RedefineClasses/? We pattern match on this. >> Fixed. >>> Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ >> Fixed the two additional blank lines - thank you for catching. >>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html >>> >>> Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. >> Done. Made it private static for now. >>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html >>> >>> Awesome! I'm glad you found this comment to remove. >> thanks to Frederic. >>> Nobody's going to miss parsed_name. This is a nice change! >> I hoped you would like that :-) >> >> thanks for the review, >> Karen >>> Thanks, >>> Coleen >>> >>> On 7/21/16 1:23 PM, Karen Kinnear wrote: >>>> Please review: >>>> https://bugs.openjdk.java.net/browse/JDK-8162340 >>>> >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ >>>> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev >>>> >>>> When moving the check from resolve_from_stream to set_package, I removed >>>> the no longer need parsed_class (!) which I should have cleaned up when >>>> tightening the placeholder table cleanup years ago. >>>> >>>> Tests run: >>>> 1. updated VMAnonymousClass test >>>> 2. jcks >>>> 3. rbt hs-nightly-runtime linux-x64 in progress >>>> >>>> thanks, >>>> Karen >>>> >>>> > From coleen.phillimore at oracle.com Tue Jul 26 22:34:44 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jul 2016 18:34:44 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <3218ED6D-4B9C-4C74-83A6-D9CD2DB88494@oracle.com> References: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> <5f805e1a-6cb6-a58b-c13c-3d75176eda6c@oracle.com> <3218ED6D-4B9C-4C74-83A6-D9CD2DB88494@oracle.com> Message-ID: <02b0f376-382b-4e34-795e-e8d988a2801d@oracle.com> Looks good! Coleen On 7/26/16 6:18 PM, Karen Kinnear wrote: > I updated the web rev after all - with Coleen?s suggested changes and shortened new comment lines. > > http://cr.openjdk.java.net/~acorn/8162340.hs.3/webrev/ > > I will push once I hear from David. > > thanks all, > Karen > >> On Jul 26, 2016, at 1:50 PM, Coleen Phillimore wrote: >> >> >> Thanks! >> Coleen >> >> On 7/26/16 1:31 PM, Karen Kinnear wrote: >>> Coleen, >>> >>> Thank you for the reminder on this review - >>> >>>> On Jul 21, 2016, at 6:45 PM, Coleen Phillimore wrote: >>>> >>>> >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>>> >>>> +// Handles unsafe_DefineAnonymousClass and redefineclasses >>>> +// redefinedclasses do not add to the class hierarchy >>>> >>>> Can you change /redefineclasses/RedefineClasses/? We pattern match on this. >>> Fixed. >>>> Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ >>> Fixed the two additional blank lines - thank you for catching. >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>> >>>> Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. >>> Done. Made it private static for now. >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html >>>> >>>> Awesome! I'm glad you found this comment to remove. >>> thanks to Frederic. >>>> Nobody's going to miss parsed_name. This is a nice change! >>> I hoped you would like that :-) >>> >>> thanks for the review, >>> Karen >>>> Thanks, >>>> Coleen >>>> >>>> On 7/21/16 1:23 PM, Karen Kinnear wrote: >>>>> Please review: >>>>> https://bugs.openjdk.java.net/browse/JDK-8162340 >>>>> >>>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ >>>>> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev >>>>> >>>>> When moving the check from resolve_from_stream to set_package, I removed >>>>> the no longer need parsed_class (!) which I should have cleaned up when >>>>> tightening the placeholder table cleanup years ago. >>>>> >>>>> Tests run: >>>>> 1. updated VMAnonymousClass test >>>>> 2. jcks >>>>> 3. rbt hs-nightly-runtime linux-x64 in progress >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> From david.holmes at oracle.com Wed Jul 27 01:46:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 11:46:11 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> Message-ID: <523ad277-d788-3967-3f5e-499c14062684@oracle.com> On 27/07/2016 7:38 AM, Daniel D. Daugherty wrote: > I've made some manual updates to both bugs and will keep an eye > on JDK-8161258. As it goes through it's phases I'll try to make > the same updates to JDK-8161259. Thanks Dan - much appreciated. David > Dan > > > On 7/26/16 2:21 PM, David Holmes wrote: >> The patch for this used the wrong bug ID - 8161258 instead of 8161259. >> >> Not sure what I'm going to be able to do about that :( >> >> David >> ----- >> >> On 26/07/2016 11:12 AM, David Holmes wrote: >>> On 25/07/2016 3:01 PM, David Holmes wrote: >>>> This all looks good. Approval is now in place. Just waiting for final >>>> conformation this builds okay for Aarch64 folk. >>> >>> That confirmation was sent to compiler-dev so the changes have been >>> pushed. >>> >>> David >>> >>>> Thanks, >>>> David >>>> >>>> On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>>> I see the typo was actually much bigger than I thought :) Presumably >>>>>> the >>>>> Well, I edited it some more ... this time I replaced the webrev >>>>> in-place, >>>>> webrev.05 is fixed now. >>>>> >>>>> I really should have an aarch64 machine :) >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 21. Juli 2016 12:00 >>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>> >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>> >>>>>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Copyright of register_definitions_x86.cpp is already fixed in >>>>>>> hs-comp, >>>>>>> I'll skip it to avoid merges. >>>>>> >>>>>> This isn't going into hs-comp so I don't know when the two will >>>>>> collide. >>>>>> I would deal with it anyway - I can just apply the patch without >>>>>> committing, deal with any merges, and then commit as you. >>>>>> >>>>>>> I fixed the others. New webrevs, also with Coleens fixes: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/ >>>>>> >>>>>> I see the typo was actually much bigger than I thought :) Presumably >>>>>> the >>>>>> INLCUDE typo caused it to be missed by a global search replace. >>>>>> >>>>>>> I also did another zero build configured as follows: >>>>>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- >>>>>> variants=zero >>>>>>> on linuxx86_64. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 21. Juli 2016 05:26 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>> newPfmIncl/webrev.04/ >>>>>>>>> >>>>>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >>>>>>>> CompileJvm.gmk >>>>>>>>> and reverts the change to the aarch define in >>>>>>>>> vmStructs_jvmci.cpp. I >>>>>>>> documented >>>>>>>>> what I learned about the platform defines in macros.hpp. >>>>>>>> >>>>>>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) >>>>>>>> and >>>>>>>> the lingering _32 the only nit I have left is a handful of >>>>>>>> copyright >>>>>>>> updates: >>>>>>>> >>>>>>>> src/cpu/x86/vm/register_definitions_x86.cpp: >>>>>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >>>>>>>> src/share/vm/runtime/semaphore.hpp: >>>>>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >>>>>>>> src/cpu/ppc/vm/templateTable_ppc.hpp >>>>>>>> >>>>>>>> Then all we need is confirmation that all the open platforms that >>>>>>>> Oracle >>>>>>>> doesn't also build (aarch64 and Zero) build and run successfully >>>>>>>> after >>>>>>>> this change. >>>>>>>> >>>>>>>> I will sponsor this (in case that wasn't clear) but may have to >>>>>>>> delay it >>>>>>>> until after we sync up the hs forest with the CPU changes now in >>>>>>>> jdk9/dev. I will rebase and handle any merging if needed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> OK, to get this through I will add >>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>> and revert this one and only place it needs to be used in the >>>>>>>>>> vmStructs_jvmci.cpp. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such >>>>>> cleanups >>>>>>>>>> should >>>>>>>>>>> not be in this change. >>>>>>>>>> >>>>>>>>>> I did not know they had a 64-bit C1 - interesting. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for doing the closed changes! >>>>>>>>>> >>>>>>>>>> You're welcome. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>> files. >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> that's great what you are saying and just the design I would >>>>>>>>>>>>> expect! >>>>>>>>>>>>>> We did not want to have to >>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for >>>>>>>>>>>>>> "64-bit >>>>>> ARM" >>>>>>>> so >>>>>>>>>>>>>> we worked with the Open port to ensure that shared code >>>>>> guarded >>>>>>>> by >>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>>>>> identify >>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a >>>>>>>>>>>>>> handful of >>>>>>>>>> places >>>>>>>>>>>>>> that needed it. And sometimes we have to be careful and >>>>>>>>>>>>>> ensure >>>>>>>> that >>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>>> >>>>>>>>>>>>> I think as a consequence the open AARCH port should define >>>>>>>>>>>>> ARM, >>>>>>>> too. >>>>>>>>>>>> >>>>>>>>>>>> I would not want to do this and certainly not as part of this >>>>>>>>>>>> change. >>>>>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, >>>>>>>>>>>> but not >>>>>>>>>>>> right now, please. >>>>>>>>>>>> >>>>>>>>>>>>> I checked the occurrences and only see three places where this >>>>>> would >>>>>>>>>> have >>>>>>>>>>>>> an effect and would have to be fixed somehow: >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>>>>>>>> [610] #if defined(AARCH64) && >>>>>>>>>>>>> !defined(ARM) >>>>>>>>>>>>> ==> Would this break the closed port if defined? >>>>>>>>>>>> >>>>>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 >>>>>>>>>>>> sources. >>>>>>>>>>>> >>>>>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was >>>>>> used) >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>>>>>>>> load_item_force[253] #if !defined(ARM) && >>>>>>>>>>>>> !defined(E500V2) >>>>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>>>>>>>> [1154] #ifdef ARM >>>>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>>> >>>>>>>>>>>> I don't think the open port has C1 so it would ignore the above >>>>>>>>>>>> files >>>>>>>>>>>> anyway. >>>>>>>>>>>> >>>>>>>>>>>>> All the cases below are pointless. >>>>>>>>>>>>> >>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>>>> defines, but >>>>>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>>>>> conditional >>>>>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>>>> I think it's quite misleading to have two defines that are 99% >>>>>>>> equivalent. >>>>>>>>>>>>> If we really need a special case here, you should define - >>>>>>>> DARM_CLOSED >>>>>>>>>>>>> or the like in your closed port. Such a name would make clear >>>>>> what's >>>>>>>> the >>>>>>>>>>>>> issue. At least, only your closed port has this problem. >>>>>>>>>>>> >>>>>>>>>>>> I really do not want to make any changes to this - ignoring the >>>>>> include >>>>>>>>>>>> macro changes everything we have is working perfectly fine just >>>>>>>>>>>> the >>>>>>>> way >>>>>>>>>>>> the defines are. So I don't want to see this change potentially >>>>>>>>>>>> break >>>>>>>>>>>> that through incidental changes. >>>>>>>>>>>> >>>>>>>>>>>> I do not see having the following is a big issue: >>>>>>>>>>>> >>>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>> >>>>>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and >>>>>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that define >>>>>>>> intend >>>>>>>>>> it to >>>>>>>>>>>> mean. It certainly is a lot better than interpreting what the >>>>>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the >>>>>>>>>> need to >>>>>>>>>>>> perform some of the changes as noted above. >>>>>>>>>>>> >>>>>>>>>>>> I'm preparing the review of the internal changes we need to >>>>>>>> accompany >>>>>>>>>> this. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These should not break the open port if ARM gets defined, >>>>>>>>>>>>> or can >>>>>> be >>>>>>>>>> fixed >>>>>>>>>>>> easily. >>>>>>>>>>>>> --------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>>>> print[1519] #elif defined(ARM) >>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>>>> >>>>>>>>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>>>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>>>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>>>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == >>>>>>>>>>>>> cpu_register) >>>>>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == >>>>>>>>>>>>> cpu_register) >>>>>>>>>>>>> ==> Just an assertion. Will just relax the check if defined >>>>>>>>>>>>> in open >>>>>>>>>> AARCH64. >>>>>>>>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>>>>>>>> [70] #if defined(ARM) || >>>>>>>>>>>>> defined(AARCH64) || >>>>>>>>>>>> defined(PPC64) >>>>>>>>>>>>> ==> Fine: || >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>>>>>>>> [447] #if defined(SPARC) || >>>>>>>>>>>>> defined(ARM) || >>>>>>>>>>>> defined(PPC) || defined(AARCH64) >>>>>>>>>>>>> [537] #if defined(X86) || >>>>>>>>>>>>> defined(ARM) || >>>>>>>>>>>> defined(AARCH64) >>>>>>>>>>>>> ==> Fine: || >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>>>>>>>> defined[162] #if defined(IA32) || >>>>>>>>>>>>> defined(AMD64) || >>>>>>>>>>>> defined(ARM) >>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>>>>>>>> [1358] #if defined(IA32) || >>>>>>>>>>>>> defined(AMD64) || >>>>>>>>>>>> defined(ARM) >>>>>>>>>>>>> ==> Just defines a method which would be unused, should be >>>>>>>>>>>>> fine. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These are in code not used in the open AARCH64 port: >>>>>>>>>>>>> -------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>>>> [215] #elif defined(ARM) >>>>>>>>>>>>> >>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>>>>>>>> [434] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, >>>>>>>>>>>>> __powerpc__, >>>>>>>> ARM, >>>>>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>>>>>>>> >>>>>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>>>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, >>>>>>>>>>>>> __powerpc__, >>>>>>>> ARM, >>>>>>>>>>>> ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>>>> store[164] #if !defined(ARM) && >>>>>>>>>>>>> !defined(M68K) >>>>>>>>>>>>> store_ptr[171] #if !defined(ARM) && >>>>>>>>>>>>> !defined(M68K) >>>>>>>>>>>>> add[178] #ifdef ARM >>>>>>>>>>>>> add_ptr[190] #ifdef ARM >>>>>>>>>>>>> xchg[230] #ifdef ARM >>>>>>>>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>>>>>>>> cmpxchg[275] #ifdef ARM >>>>>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>>>> add[172] #ifdef ARM >>>>>>>>>>>>> add_ptr[184] #ifdef ARM >>>>>>>>>>>>> xchg[224] #ifdef ARM >>>>>>>>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>>>>>>>> cmpxchg[269] #ifdef ARM >>>>>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>> Barrett >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390. >>>>>>>>>>>>>>> (Parisc is gone, puh!). >>>>>>>>>>>>>>> We basically patch all the shared changes onto the sources >>>>>>>>>>>>>>> after >>>>>>>>>>>>>>> getting them via our licensee channel. >>>>>>>>>>>>>>> I think you should fix your closed port not to re-use the >>>>>>>>>>>>>>> names of >>>>>>>> the >>>>>>>>>>>>>>> main openJdk platforms! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to >>>>>>>> have >>>>>>>>>> to >>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for >>>>>>>>>>>>>> "64-bit >>>>>> ARM" >>>>>>>> so >>>>>>>>>>>>>> we worked with the Open port to ensure that shared code >>>>>> guarded >>>>>>>> by >>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to >>>>>>>>>> identify >>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a >>>>>>>>>>>>>> handful of >>>>>>>>>> places >>>>>>>>>>>>>> that needed it. And sometimes we have to be careful and >>>>>>>>>>>>>> ensure >>>>>>>> that >>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This has all been working quite nicely, as the include guards >>>>>>>>>>>>>> used, >>>>>> for >>>>>>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM - >>>>>> which >>>>>>>>>> are >>>>>>>>>>>>>> never >>>>>>>>>>>>>> defined at the same time (derived from >>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>>>>>>>> But >>>>>>>>>>>>>> the >>>>>>>>>>>>>> current changes remove those unique defines and, before the >>>>>>>>>> HEADER_H >>>>>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as >>>>>>>>>> include >>>>>>>>>>>>>> guards, and that doesn't work as they are not mutually >>>>>>>>>>>>>> exclusive. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>>>> defines, but >>>>>>>>>>>>>> keeping them so they can be used as include guards (or other >>>>>>>>>> conditional >>>>>>>>>>>>>> code) when needed, and where the macros are not suitable. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have no idea what hardware is addressed by your closed >>>>>>>>>>>>>>> ports, >>>>>>>>>>>>>>> nor how you merge sources. >>>>>>>>>>>>>>> Is there also a port that sets >>>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>>> -DARM32 >>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To fix this either you define >>>>>>>>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>>>>>>>> #define ARM64 >>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>>>>>>>> Then you replace all >>>>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For ppc, when we did the port we knew (and that's all we >>>>>>>>>>>>>>> knew) >>>>>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these >>>>>>>>>>>>>>> macros >>>>>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for >>>>>>>>>> LP64/!LP64 >>>>>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed >>>>>>>>>>>>>>> port >>>>>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for >>>>>>>>>>>>>>> both >>>>>>>>>> (PPC). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But I don't think it is necessary to do any further changes >>>>>>>>>>>>>>> now, >>>>>>>>>> assuming >>>>>>>>>>>>>>> my change works for you as I adapted it. So we're all set I >>>>>>>>>>>>>>> guess! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. >>>>>>>>>>>>>>>>>> This >>>>>>>> kind >>>>>>>>>> of >>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>>>>> Aarch64 >>>>>>>>>>>> port >>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>>>>> Open >>>>>>>>>> port >>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>>>>> just >>>>>>>>>>>> something >>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that? >>>>>> You >>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>>>>>>> check every AARCH change by RedHat against your closed >>>>>> port? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The sources for the two ports are distinct so the only >>>>>>>>>>>>>>>> place we >>>>>>>> have >>>>>>>>>> to >>>>>>>>>>>>>>>> have a convention is in shared code that has CPU specific >>>>>>>>>>>>>>>> stuff >>>>>> and >>>>>>>> in >>>>>>>>>>>>>>>> the build files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the closed port sets >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes >>>>>>>>>>>>>>>> them. >>>>>>>>>>>>>> Whenever >>>>>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was >>>>>>>> referring >>>>>>>>>> to >>>>>>>>>>>>>> our >>>>>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open >>>>>>>> Aarch64 >>>>>>>>>>>> port. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We need to keep a clear distinction. Using the >>>>>>>>>>>>>>>> combination of >>>>>>>>>> AARCH64 >>>>>>>>>>>>>>>> and ARM is not so clear. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You could easily have similar issues with other port groups >>>>>>>>>>>>>>>> - eg >>>>>>>> ppc64 >>>>>>>>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up >>>>>> recently, >>>>>>>>>> and >>>>>>>>>>>>>>>>> before that it sure was equivalent. And it still is the >>>>>>>>>>>>>>>>> case for >>>>>>>>>> openJDK. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Below output is grepped out of the >>>>>> make//platform_ >>>>>>>>>> files >>>>>>>>>>>> in >>>>>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined >>>>>>>> twice. >>>>>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>>>> D_GNU_SOURCE >>>>>>>>>> - >>>>>>>>>>>>>>>> DAMD64 >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>>>> D_GNU_SOURCE >>>>>>>>>> - >>>>>>>>>>>>>> DIA32 >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 - >>>>>>>>>> DCC_INTERP >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >>>>>> DCC_INTERP - >>>>>>>>>>>> DZERO - >>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>>>>>> DAMD64 >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE - >>>>>> DIA32 >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO - >>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>> runtime- >>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any >>>>>> further >>>>>>>>>>>> issues, >>>>>>>>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen >>>>>> in >>>>>>>> this >>>>>>>>>>>> new >>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined >>>>>>>>>>>>>>>>>>> at the same time. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. >>>>>>>>>>>>>>>>>> This >>>>>>>> kind >>>>>>>>>> of >>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open >>>>>>>> Aarch64 >>>>>>>>>>>> port >>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the >>>>>> Open >>>>>>>>>> port >>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - >>>>>>>>>>>>>>>>>> just >>>>>>>>>>>> something >>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >>>>>> Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>>>>>>>>>>>>> platform >>>>>> files. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should >>>>>> be >>>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just >>>>>>>>>>>>>>>>>>>>> that. >>>>>> :) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value >>>>>>>> for >>>>>>>>>> the >>>>>>>>>>>>>> ifdef >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change >>>>>>>>>>>>>>>>>>>>> that >>>>>>>> value >>>>>>>>>> to >>>>>>>>>>>>>>>> match >>>>>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to >>>>>> other >>>>>>>>>>>>>> problems >>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>> we also need that value the way it is currently >>>>>>>>>>>>>>>>>>>>> defined. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm >>>>>>>>>>>>>>>>>>>>> fresher. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H >>>>>> macro. >>>>>>>> In >>>>>>>>>>>>>> general >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. >>>>>>>>>>>>>>>>>>>> In our >>>>>>>> case >>>>>>>>>>>> ARM >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In >>>>>> contrast >>>>>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen >>>>>> to >>>>>>>>>>>>>> represent >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>> ; >>>>>>>>>> Kim >>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>> hotspot- >>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>> platform >>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>>>>> appends >>>>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>>>> CPU_HEADER_H, >>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each >>>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>> used >>>>>>>>>>>> only >>>>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>>>> should do >>>>>> it >>>>>>>> to >>>>>>>>>> get >>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>>>>> need >>>>>>>> not >>>>>>>>>>>> be >>>>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>>>>> needs >>>>>>>> to >>>>>>>>>> be >>>>>>>>>>>> an >>>>>>>>>>>>>> if- >>>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are >>>>>>>>>>>>>>>>>>>>>>>> set in >>>>>>>>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>> in the same statement as the >>>>>> INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from >>>>>> the >>>>>>>>>> closed >>>>>>>>>>>>>> part >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So >>>>>> we >>>>>>>> get >>>>>>>>>>>> both >>>>>>>>>>>>>>>>>> defined >>>>>>>>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to >>>>>>>>>> understand >>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to >>>>>>>> be, >>>>>>>>>> as >>>>>>>>>>>> we >>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the >>>>>>>>>>>>>>>>>>>>>>> current >>>>>>>>>> problem, >>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>> ; >>>>>>>>>>>> Kim >>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>> hotspot- >>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>> platform >>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more >>>>>>>>>>>>>>>>>>>>>>>>>> detail! >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> ; >>>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>>>> hotspot- >>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>>> platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz >>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications >>>>>> and >>>>>>>>>>>>>> comments >>>>>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch >>>>>>>> directory, >>>>>>>>>> but >>>>>>>>>>>> I >>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated >>>>>>>>>>>>>>>>>>>>>>>>>>> files. >>>>>>>>>> (Sorry I >>>>>>>>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what >>>>>> needs >>>>>>>> to >>>>>>>>>>>> be >>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send >>>>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>> :).) >>>>>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a >>>>>>>>>>>>>>>>>>>>>>>>>> directory >>>>>> that >>>>>>>> has >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it >>>>>>>>>>>>>>>>>>>>>>>>>> builds to >>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64 >>>>>>>>>> header >>>>>>>>>>>>>> files if >>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that >>>>>>>>>>>>>>>>>>>>>>>>>>> dispatches >>>>>>>>>>>> internally >>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did >>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>> hold: >>>>>>>>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was >>>>>> a >>>>>>>>>>>> common >>>>>>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to >>>>>> avoid >>>>>>>> this >>>>>>>>>>>> kind >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >>>>>>>> TARGET_SO... >>>>>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be >>>>>> moved >>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be >>>>>>>>>> elided >>>>>>>>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is >>>>>> the >>>>>>>>>>>>>> umbrella >>>>>>>>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed >>>>>>>>>>>>>>>>>>>>>>>>>> anyways. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it >>>>>> appends >>>>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>>>> CPU_HEADER_H, >>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each >>>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>> used >>>>>>>>>>>> only >>>>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>>>> should do >>>>>> it >>>>>>>> to >>>>>>>>>> get >>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names >>>>>> need >>>>>>>> not >>>>>>>>>>>> be >>>>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this >>>>>> needs >>>>>>>> to >>>>>>>>>> be >>>>>>>>>>>> an >>>>>>>>>>>>>> if- >>>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of >>>>>> WINDOWS? Is >>>>>>>>>> that >>>>>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined >>>>>>>>>>>> WINDOWS >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is >>>>>>>> defining >>>>>>>>>> - >>>>>>>>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead. >>>>>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS, >>>>>>>> but >>>>>>>>>> not >>>>>>>>>>>> in >>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the >>>>>>>>>> unused >>>>>>>>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty >>>>>> file. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> ; >>>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>>>>>>>>>>>>>>>>>>>>>>>>>>>> including >>>>>>>>>>>> platform >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz >>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's >>>>>>>> working >>>>>>>>>> on >>>>>>>>>>>> all >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>> macros >>>>>>>>>>>> and >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name >>>>>>>>>>>>>> construction >>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >>>>>>>> macros.hpp. >>>>>>>>>> But >>>>>>>>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and >>>>>> uses >>>>>>>>>> the >>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could >>>>>>>> include >>>>>>>>>>>> that >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> am as >>>>>>>> fine >>>>>>>>>>>> with >>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is >>>>>> that >>>>>>>>>> the >>>>>>>>>>>>>> linux=1 >>>>>>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros >>>>>> should >>>>>>>> be >>>>>>>>>>>>>> upper >>>>>>>>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>>>>>>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley ; >>>>>>>> hotspot- >>>>>>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>>>>> including >>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier, >>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these >>>>>> macros >>>>>>>> are >>>>>>>>>>>> only >>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody >>>>>>>> needs >>>>>>>>>> to >>>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes.hpp >>>>>>>> and >>>>>>>>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu >>>>>>>>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>> spend >>>>>>>>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted >>>>>> my >>>>>>>>>>>> current >>>>>>>>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to >>>>>> do >>>>>>>> is >>>>>>>>>>>> adding >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the >>>>>> includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker >>>>>>>>>>>> proposed >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email >>>>>>>> thread >>>>>>>>>> for >>>>>>>>>>>>>> me; it >>>>>>>>>>>>>>>>>> looks >>>>>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- >>>>>> compiler- >>>>>>>> dev >>>>>>>>>> but >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list >>>>>>>> this >>>>>>>>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details. >>>>>> I've >>>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>>> wait >>>>>>>>>>>> until >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> --- >>>>>>>> --- >>>>>>>>>> ---- >>>>>>>>>>>> --- >>>>>>>>>>>>>> ---- >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround >>>>>> existing >>>>>>>>>>>> #defines >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so >>>>>> far: >>>>>>>>>>>> linux=1, >>>>>>>>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the >>>>>>>> leading >>>>>>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in >>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the >>>>>>>> values. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written >>>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename) >>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets >>>>>>>>>> instead >>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example) >>>>>> are >>>>>>>>>>>> defined, >>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that >>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word >>>>>>>>>> pattern >>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use >>>>>>>> uppercase >>>>>>>>>> for >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>> --- >>>>>>>> --- >>>>>>>>>> ---- >>>>>>>>>>>> --- >>>>>>>>>>>>>> ---- >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > From david.holmes at oracle.com Wed Jul 27 02:16:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 12:16:28 +1000 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <57978A6B.6000906@oracle.com> References: <57978A6B.6000906@oracle.com> Message-ID: <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> Hi Jerry, On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: > Hi Everyone, > > I would like to have the following change reviewed: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 > > Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ > > > The stack size for this test needs to be increased to 384K for some > platforms. Is there a specific reason we set -Xss in the first place instead of just taking the platform defaults? If the platform stack settings change this test may need updating again. Thanks, David > My fix for JDK-8081770 https://bugs.openjdk.java.net/browse/JDK-8081770 > moved the functionality > from the testme.sh script to exeinvoke.c so the dependency for a local > compiler could be removed. > Because of this the stack size change needs to be applied to exeinvoke.c > file instead of the testme.sh file. > > Please let me know if you have any questions or concerns. > > Thanks, > > Jerry From david.holmes at oracle.com Wed Jul 27 02:36:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 12:36:42 +1000 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <3218ED6D-4B9C-4C74-83A6-D9CD2DB88494@oracle.com> References: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> <5f805e1a-6cb6-a58b-c13c-3d75176eda6c@oracle.com> <3218ED6D-4B9C-4C74-83A6-D9CD2DB88494@oracle.com> Message-ID: <1141a99d-ad1c-86f7-1f22-2c8ea39a6703@oracle.com> On 27/07/2016 8:18 AM, Karen Kinnear wrote: > I updated the web rev after all - with Coleen?s suggested changes and shortened new comment lines. > > http://cr.openjdk.java.net/~acorn/8162340.hs.3/webrev/ > > I will push once I hear from David. Looks good to me. Thanks for clearing up my confusion over Platform vs. System/Application loader. :) Thanks, David > thanks all, > Karen > >> On Jul 26, 2016, at 1:50 PM, Coleen Phillimore wrote: >> >> >> Thanks! >> Coleen >> >> On 7/26/16 1:31 PM, Karen Kinnear wrote: >>> Coleen, >>> >>> Thank you for the reminder on this review - >>> >>>> On Jul 21, 2016, at 6:45 PM, Coleen Phillimore wrote: >>>> >>>> >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>>> >>>> +// Handles unsafe_DefineAnonymousClass and redefineclasses >>>> +// redefinedclasses do not add to the class hierarchy >>>> >>>> Can you change /redefineclasses/RedefineClasses/? We pattern match on this. >>> Fixed. >>>> Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ >>> Fixed the two additional blank lines - thank you for catching. >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>> >>>> Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. >>> Done. Made it private static for now. >>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html >>>> >>>> Awesome! I'm glad you found this comment to remove. >>> thanks to Frederic. >>>> Nobody's going to miss parsed_name. This is a nice change! >>> I hoped you would like that :-) >>> >>> thanks for the review, >>> Karen >>>> Thanks, >>>> Coleen >>>> >>>> On 7/21/16 1:23 PM, Karen Kinnear wrote: >>>>> Please review: >>>>> https://bugs.openjdk.java.net/browse/JDK-8162340 >>>>> >>>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ >>>>> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev >>>>> >>>>> When moving the check from resolve_from_stream to set_package, I removed >>>>> the no longer need parsed_class (!) which I should have cleaned up when >>>>> tightening the placeholder table cleanup years ago. >>>>> >>>>> Tests run: >>>>> 1. updated VMAnonymousClass test >>>>> 2. jcks >>>>> 3. rbt hs-nightly-runtime linux-x64 in progress >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> >> > From gerald.thornbrugh at oracle.com Wed Jul 27 02:55:53 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 26 Jul 2016 20:55:53 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> Message-ID: <579822B9.4040700@oracle.com> Hi David, > Hi Jerry, > > On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >> Hi Everyone, >> >> I would like to have the following change reviewed: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >> >> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >> >> >> The stack size for this test needs to be increased to 384K for some >> platforms. > > Is there a specific reason we set -Xss in the first place instead of > just taking the platform defaults? If the platform stack settings > change this test may need updating again. It was my understand (maybe incorrectly) that setting -Xss was an attempt to limit the memory and time resources the test takes. Using the smallest stack size allowable will allocate less memory and reduce the amount of time the test takes. Since I think Fred wrote the test he would know better than I would. Fred, what is the reason behind specifying "-Xss" for this test? I have thought about the test harness setting an environment variable and/or a java property to the correct minimum values for "-Xss" depending upon the architecture the test is running on. The tests could then use the value to start each test. That way each test could be tailored for the specific architecture. After looking into this it looks the implementation would be significant and would be outside the scope of this bug fix. Thanks, Jerry > > Thanks, > David > >> My fix for JDK-8081770 https://bugs.openjdk.java.net/browse/JDK-8081770 >> moved the functionality >> from the testme.sh script to exeinvoke.c so the dependency for a local >> compiler could be removed. >> Because of this the stack size change needs to be applied to exeinvoke.c >> file instead of the testme.sh file. >> >> Please let me know if you have any questions or concerns. >> >> Thanks, >> >> Jerry From david.holmes at oracle.com Wed Jul 27 03:43:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 13:43:06 +1000 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <579822B9.4040700@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> Message-ID: <6fedd95c-b0fb-d029-a986-2258b10b5692@oracle.com> On 27/07/2016 12:55 PM, Gerald Thornbrugh wrote: > Hi David, >> Hi Jerry, >> >> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>> Hi Everyone, >>> >>> I would like to have the following change reviewed: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>> >>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>> >>> >>> The stack size for this test needs to be increased to 384K for some >>> platforms. >> >> Is there a specific reason we set -Xss in the first place instead of >> just taking the platform defaults? If the platform stack settings >> change this test may need updating again. > > It was my understand (maybe incorrectly) that setting -Xss was an > attempt to limit the memory and time > resources the test takes. Using the smallest stack size allowable will > allocate less memory and reduce the > amount of time the test takes. Since I think Fred wrote the test he > would know better than I would. I did a simple test and found that triggerring a stackoverflow is so fast it is inconsequential. > Fred, what is the reason behind specifying "-Xss" for this test? > > I have thought about the test harness setting an environment variable > and/or a java property to the correct > minimum values for "-Xss" depending upon the architecture the test is > running on. The tests could then use > the value to start each test. That way each test could be tailored for > the specific architecture. After looking into > this it looks the implementation would be significant and would be > outside the scope of this bug fix. Definitely don't want to go that way :) Avoid architecture specific test parameters at all costs. Cheers, David > Thanks, > > Jerry >> >> Thanks, >> David >> >>> My fix for JDK-8081770 https://bugs.openjdk.java.net/browse/JDK-8081770 >>> moved the functionality >>> from the testme.sh script to exeinvoke.c so the dependency for a local >>> compiler could be removed. >>> Because of this the stack size change needs to be applied to exeinvoke.c >>> file instead of the testme.sh file. >>> >>> Please let me know if you have any questions or concerns. >>> >>> Thanks, >>> >>> Jerry > From goetz.lindenmaier at sap.com Wed Jul 27 09:40:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Jul 2016 09:40:26 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <523ad277-d788-3967-3f5e-499c14062684@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> <523ad277-d788-3967-3f5e-499c14062684@oracle.com> Message-ID: <5a852442473f4ba18ac4e5fa190fdf34@DEWDFE13DE09.global.corp.sap> Hi, I'm sorry, I messed this up. Thanks for looking after this. In my first webrev, the bugID was correct, after that it's one off. I don't know what happened. Should "8161258: [Win] Timer functionality is broken after JDK-8089563" be reopened so that it gets a new bugID? Btw, why isn't jcheck catching this? Best regards and sorry again, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 27. Juli 2016 03:46 > To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 27/07/2016 7:38 AM, Daniel D. Daugherty wrote: > > I've made some manual updates to both bugs and will keep an eye > > on JDK-8161258. As it goes through it's phases I'll try to make > > the same updates to JDK-8161259. > > Thanks Dan - much appreciated. > > David > > > Dan > > > > > > On 7/26/16 2:21 PM, David Holmes wrote: > >> The patch for this used the wrong bug ID - 8161258 instead of 8161259. > >> > >> Not sure what I'm going to be able to do about that :( > >> > >> David > >> ----- > >> > >> On 26/07/2016 11:12 AM, David Holmes wrote: > >>> On 25/07/2016 3:01 PM, David Holmes wrote: > >>>> This all looks good. Approval is now in place. Just waiting for final > >>>> conformation this builds okay for Aarch64 folk. > >>> > >>> That confirmation was sent to compiler-dev so the changes have been > >>> pushed. > >>> > >>> David > >>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> > >>>>>> I see the typo was actually much bigger than I thought :) Presumably > >>>>>> the > >>>>> Well, I edited it some more ... this time I replaced the webrev > >>>>> in-place, > >>>>> webrev.05 is fixed now. > >>>>> > >>>>> I really should have an aarch64 machine :) > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Donnerstag, 21. Juli 2016 12:00 > >>>>>> To: Lindenmaier, Goetz ; Kim Barrett > >>>>>> > >>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>> > >>>>>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> Copyright of register_definitions_x86.cpp is already fixed in > >>>>>>> hs-comp, > >>>>>>> I'll skip it to avoid merges. > >>>>>> > >>>>>> This isn't going into hs-comp so I don't know when the two will > >>>>>> collide. > >>>>>> I would deal with it anyway - I can just apply the patch without > >>>>>> committing, deal with any merges, and then commit as you. > >>>>>> > >>>>>>> I fixed the others. New webrevs, also with Coleens fixes: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > newPfmIncl/webrev.05/ > >>>>>> > >>>>>> I see the typo was actually much bigger than I thought :) Presumably > >>>>>> the > >>>>>> INLCUDE typo caused it to be missed by a global search replace. > >>>>>> > >>>>>>> I also did another zero build configured as follows: > >>>>>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- > >>>>>> variants=zero > >>>>>>> on linuxx86_64. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> David > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Donnerstag, 21. Juli 2016 05:26 > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>> newPfmIncl/webrev.04/ > >>>>>>>>> > >>>>>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > >>>>>>>> CompileJvm.gmk > >>>>>>>>> and reverts the change to the aarch define in > >>>>>>>>> vmStructs_jvmci.cpp. I > >>>>>>>> documented > >>>>>>>>> what I learned about the platform defines in macros.hpp. > >>>>>>>> > >>>>>>>> Thanks - much appreciated. Other than Coleen's typo (well > spotted!) > >>>>>>>> and > >>>>>>>> the lingering _32 the only nit I have left is a handful of > >>>>>>>> copyright > >>>>>>>> updates: > >>>>>>>> > >>>>>>>> src/cpu/x86/vm/register_definitions_x86.cpp: > >>>>>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > >>>>>>>> src/share/vm/runtime/semaphore.hpp: > >>>>>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: > >>>>>>>> src/cpu/ppc/vm/templateTable_ppc.hpp > >>>>>>>> > >>>>>>>> Then all we need is confirmation that all the open platforms that > >>>>>>>> Oracle > >>>>>>>> doesn't also build (aarch64 and Zero) build and run successfully > >>>>>>>> after > >>>>>>>> this change. > >>>>>>>> > >>>>>>>> I will sponsor this (in case that wasn't clear) but may have to > >>>>>>>> delay it > >>>>>>>> until after we sync up the hs forest with the CPU changes now in > >>>>>>>> jdk9/dev. I will rebase and handle any merging if needed. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi David, > >>>>>>>>>>> > >>>>>>>>>>> OK, to get this through I will add > >>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>> and revert this one and only place it needs to be used in the > >>>>>>>>>> vmStructs_jvmci.cpp. > >>>>>>>>>> > >>>>>>>>>> Thanks. > >>>>>>>>>> > >>>>>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such > >>>>>> cleanups > >>>>>>>>>> should > >>>>>>>>>>> not be in this change. > >>>>>>>>>> > >>>>>>>>>> I did not know they had a 64-bit C1 - interesting. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks for doing the closed changes! > >>>>>>>>>> > >>>>>>>>>> You're welcome. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>>>>>> > >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>> files. > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>> > >>>>>>>>>>>>> that's great what you are saying and just the design I would > >>>>>>>>>>>>> expect! > >>>>>>>>>>>>>> We did not want to have to > >>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for > >>>>>>>>>>>>>> "64-bit > >>>>>> ARM" > >>>>>>>> so > >>>>>>>>>>>>>> we worked with the Open port to ensure that shared > code > >>>>>> guarded > >>>>>>>> by > >>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was > used to > >>>>>>>>>> identify > >>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a > >>>>>>>>>>>>>> handful of > >>>>>>>>>> places > >>>>>>>>>>>>>> that needed it. And sometimes we have to be careful and > >>>>>>>>>>>>>> ensure > >>>>>>>> that > >>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think as a consequence the open AARCH port should > define > >>>>>>>>>>>>> ARM, > >>>>>>>> too. > >>>>>>>>>>>> > >>>>>>>>>>>> I would not want to do this and certainly not as part of this > >>>>>>>>>>>> change. > >>>>>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, > >>>>>>>>>>>> but not > >>>>>>>>>>>> right now, please. > >>>>>>>>>>>> > >>>>>>>>>>>>> I checked the occurrences and only see three places where > this > >>>>>> would > >>>>>>>>>> have > >>>>>>>>>>>>> an effect and would have to be fixed somehow: > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>>>>>>>>>> [610] #if defined(AARCH64) && > >>>>>>>>>>>>> !defined(ARM) > >>>>>>>>>>>>> ==> Would this break the closed port if defined? > >>>>>>>>>>>> > >>>>>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 > >>>>>>>>>>>> sources. > >>>>>>>>>>>> > >>>>>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 > was > >>>>>> used) > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>>>>>>>>>> load_item_force[253] #if !defined(ARM) && > >>>>>>>>>>>>> !defined(E500V2) > >>>>>>>>>>>>> ==> Would this break the open port if defined? > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>>>>>>>>>> [1154] #ifdef ARM > >>>>>>>>>>>>> ==> Would this break the open port if defined? > >>>>>>>>>>>> > >>>>>>>>>>>> I don't think the open port has C1 so it would ignore the > above > >>>>>>>>>>>> files > >>>>>>>>>>>> anyway. > >>>>>>>>>>>> > >>>>>>>>>>>>> All the cases below are pointless. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those > >>>>>>>>>>>>>> defines, but > >>>>>>>>>>>>>> keeping them so they can be used as include guards (or > other > >>>>>>>>>> conditional > >>>>>>>>>>>>>> code) when needed, and where the macros are not > suitable. > >>>>>>>>>>>>> I think it's quite misleading to have two defines that are > 99% > >>>>>>>> equivalent. > >>>>>>>>>>>>> If we really need a special case here, you should define - > >>>>>>>> DARM_CLOSED > >>>>>>>>>>>>> or the like in your closed port. Such a name would make > clear > >>>>>> what's > >>>>>>>> the > >>>>>>>>>>>>> issue. At least, only your closed port has this problem. > >>>>>>>>>>>> > >>>>>>>>>>>> I really do not want to make any changes to this - ignoring > the > >>>>>> include > >>>>>>>>>>>> macro changes everything we have is working perfectly fine > just > >>>>>>>>>>>> the > >>>>>>>> way > >>>>>>>>>>>> the defines are. So I don't want to see this change > potentially > >>>>>>>>>>>> break > >>>>>>>>>>>> that through incidental changes. > >>>>>>>>>>>> > >>>>>>>>>>>> I do not see having the following is a big issue: > >>>>>>>>>>>> > >>>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>> - > DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>> > >>>>>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 > port, and > >>>>>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that > define > >>>>>>>> intend > >>>>>>>>>> it to > >>>>>>>>>>>> mean. It certainly is a lot better than interpreting what the > >>>>>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this > removes the > >>>>>>>>>> need to > >>>>>>>>>>>> perform some of the changes as noted above. > >>>>>>>>>>>> > >>>>>>>>>>>> I'm preparing the review of the internal changes we need to > >>>>>>>> accompany > >>>>>>>>>> this. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> ----- > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> These should not break the open port if ARM gets defined, > >>>>>>>>>>>>> or can > >>>>>> be > >>>>>>>>>> fixed > >>>>>>>>>>>> easily. > >>>>>>>>>>>>> --------------------------------------------------------- > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>>>>>>>> print[1519] #elif defined(ARM) > >>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os/linux/vm/os_linux.cpp: > >>>>>>>>>>>>> dll_load[1796] #elif (defined ARM) > >>>>>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/opto/matcher.cpp: > >>>>>>>>>>>>> init_first_stack_mask[558] #ifdef ARM > >>>>>>>>>>>>> ==> Should be ARM32 (Is under !LP64). > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == > >>>>>>>>>>>>> cpu_register) > >>>>>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == > >>>>>>>>>>>>> cpu_register) > >>>>>>>>>>>>> ==> Just an assertion. Will just relax the check if defined > >>>>>>>>>>>>> in open > >>>>>>>>>> AARCH64. > >>>>>>>>>>>>> But maybe should be guarded by __SOFTFP__. > >>>>>>>>>>>>> [70] #if defined(ARM) || > >>>>>>>>>>>>> defined(AARCH64) || > >>>>>>>>>>>> defined(PPC64) > >>>>>>>>>>>>> ==> Fine: || > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>>>>>>>>>> [447] #if defined(SPARC) || > >>>>>>>>>>>>> defined(ARM) || > >>>>>>>>>>>> defined(PPC) || defined(AARCH64) > >>>>>>>>>>>>> [537] #if defined(X86) || > >>>>>>>>>>>>> defined(ARM) || > >>>>>>>>>>>> defined(AARCH64) > >>>>>>>>>>>>> ==> Fine: || > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>>>>>>>>>> defined[162] #if defined(IA32) || > >>>>>>>>>>>>> defined(AMD64) || > >>>>>>>>>>>> defined(ARM) > >>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>>>>>>>>>> [1358] #if defined(IA32) || > >>>>>>>>>>>>> defined(AMD64) || > >>>>>>>>>>>> defined(ARM) > >>>>>>>>>>>>> ==> Just defines a method which would be unused, should > be > >>>>>>>>>>>>> fine. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> These are in code not used in the open AARCH64 port: > >>>>>>>>>>>>> -------------------------------------------------- > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>>>>>>>> [215] #elif defined(ARM) > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>>>>>>>> [102] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** > os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>>>>>>>>>> [31] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>>>>>>>> [102] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** > os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>>>>>>>>>> [31] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** share/vm/utilities/macros.hpp: > >>>>>>>>>>>>> [434] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>>>>>>>> dll_load[1508] #elif (defined ARM) > >>>>>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, > >>>>>>>>>>>>> __powerpc__, > >>>>>>>> ARM, > >>>>>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>>>>>>>>>> dll_load[1725] #elif (defined ARM) > >>>>>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, > >>>>>>>>>>>>> __powerpc__, > >>>>>>>> ARM, > >>>>>>>>>>>> ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>>>>>>>> store[164] #if !defined(ARM) && > >>>>>>>>>>>>> !defined(M68K) > >>>>>>>>>>>>> store_ptr[171] #if !defined(ARM) && > >>>>>>>>>>>>> !defined(M68K) > >>>>>>>>>>>>> add[178] #ifdef ARM > >>>>>>>>>>>>> add_ptr[190] #ifdef ARM > >>>>>>>>>>>>> xchg[230] #ifdef ARM > >>>>>>>>>>>>> xchg_ptr[253] #ifdef ARM > >>>>>>>>>>>>> cmpxchg[275] #ifdef ARM > >>>>>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>>>>>>>> add[172] #ifdef ARM > >>>>>>>>>>>>> add_ptr[184] #ifdef ARM > >>>>>>>>>>>>> xchg[224] #ifdef ARM > >>>>>>>>>>>>> xchg_ptr[247] #ifdef ARM > >>>>>>>>>>>>> cmpxchg[269] #ifdef ARM > >>>>>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >>>>>> Barrett > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>>>> files. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and > s390. > >>>>>>>>>>>>>>> (Parisc is gone, puh!). > >>>>>>>>>>>>>>> We basically patch all the shared changes onto the > sources > >>>>>>>>>>>>>>> after > >>>>>>>>>>>>>>> getting them via our licensee channel. > >>>>>>>>>>>>>>> I think you should fix your closed port not to re-use the > >>>>>>>>>>>>>>> names of > >>>>>>>> the > >>>>>>>>>>>>>>> main openJdk platforms! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not > want to > >>>>>>>> have > >>>>>>>>>> to > >>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for > >>>>>>>>>>>>>> "64-bit > >>>>>> ARM" > >>>>>>>> so > >>>>>>>>>>>>>> we worked with the Open port to ensure that shared > code > >>>>>> guarded > >>>>>>>> by > >>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was > used to > >>>>>>>>>> identify > >>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a > >>>>>>>>>>>>>> handful of > >>>>>>>>>> places > >>>>>>>>>>>>>> that needed it. And sometimes we have to be careful and > >>>>>>>>>>>>>> ensure > >>>>>>>> that > >>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This has all been working quite nicely, as the include > guards > >>>>>>>>>>>>>> used, > >>>>>> for > >>>>>>>>>>>>>> example, TARGET_ARCH_AARCH64 and > TARGET_ARCH_ARM - > >>>>>> which > >>>>>>>>>> are > >>>>>>>>>>>>>> never > >>>>>>>>>>>>>> defined at the same time (derived from > >>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH). > >>>>>>>>>>>> But > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>> current changes remove those unique defines and, > before the > >>>>>>>>>> HEADER_H > >>>>>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and > ARM as > >>>>>>>>>> include > >>>>>>>>>>>>>> guards, and that doesn't work as they are not mutually > >>>>>>>>>>>>>> exclusive. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those > >>>>>>>>>>>>>> defines, but > >>>>>>>>>>>>>> keeping them so they can be used as include guards (or > other > >>>>>>>>>> conditional > >>>>>>>>>>>>>> code) when needed, and where the macros are not > suitable. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> David > >>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have no idea what hardware is addressed by your > closed > >>>>>>>>>>>>>>> ports, > >>>>>>>>>>>>>>> nor how you merge sources. > >>>>>>>>>>>>>>> Is there also a port that sets > >>>>>>>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>>>>>>> -DARM > >>>>>>>>>>>>>>> -DARM32 > >>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> To fix this either you define > >>>>>>>>>>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>>>>>>>>>> #define ARM64 > >>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. > >>>>>>>>>>>>>>> Then you replace all > >>>>>>>>>>>>>>> #ifdef AARCH64 > >>>>>>>>>>>>>>> by > >>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>>>>>>>>>> or maybe it suffices altogether f you replace > >>>>>>>>>>>>>>> #ifdef AARCH64 > >>>>>>>>>>>>>>> by > >>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> For ppc, when we did the port we knew (and that's all > we > >>>>>>>>>>>>>>> knew) > >>>>>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these > >>>>>>>>>>>>>>> macros > >>>>>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two > for > >>>>>>>>>> LP64/!LP64 > >>>>>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the > closed > >>>>>>>>>>>>>>> port > >>>>>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared > for > >>>>>>>>>>>>>>> both > >>>>>>>>>> (PPC). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> But I don't think it is necessary to do any further changes > >>>>>>>>>>>>>>> now, > >>>>>>>>>> assuming > >>>>>>>>>>>>>>> my change works for you as I adapted it. So we're all set I > >>>>>>>>>>>>>>> guess! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just > xxx. > >>>>>>>>>>>>>>>>>> This > >>>>>>>> kind > >>>>>>>>>> of > >>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the > Open > >>>>>>>> Aarch64 > >>>>>>>>>>>> port > >>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is > for the > >>>>>> Open > >>>>>>>>>> port > >>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I > wonder - > >>>>>>>>>>>>>>>>>> just > >>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be > restored? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle > that? > >>>>>> You > >>>>>>>>>> have > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> check every AARCH change by RedHat against your > closed > >>>>>> port? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The sources for the two ports are distinct so the only > >>>>>>>>>>>>>>>> place we > >>>>>>>> have > >>>>>>>>>> to > >>>>>>>>>>>>>>>> have a convention is in shared code that has CPU > specific > >>>>>>>>>>>>>>>> stuff > >>>>>> and > >>>>>>>> in > >>>>>>>>>>>>>>>> the build files. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>>>>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>>>>>>>>>> -DAARCH64 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> the closed port sets > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>>>>>>>> -DARM > >>>>>>>>>>>>>>>> -DAARCH64 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that > distinguishes > >>>>>>>>>>>>>>>> them. > >>>>>>>>>>>>>> Whenever > >>>>>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it > is/was > >>>>>>>> referring > >>>>>>>>>> to > >>>>>>>>>>>>>> our > >>>>>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the > open > >>>>>>>> Aarch64 > >>>>>>>>>>>> port. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same > position. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> We need to keep a clear distinction. Using the > >>>>>>>>>>>>>>>> combination of > >>>>>>>>>> AARCH64 > >>>>>>>>>>>>>>>> and ARM is not so clear. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> You could easily have similar issues with other port > groups > >>>>>>>>>>>>>>>> - eg > >>>>>>>> ppc64 > >>>>>>>>>>>>>>>> vs ppc32 vs ppcle. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came > up > >>>>>> recently, > >>>>>>>>>> and > >>>>>>>>>>>>>>>>> before that it sure was equivalent. And it still is the > >>>>>>>>>>>>>>>>> case for > >>>>>>>>>> openJDK. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Below output is grepped out of the > >>>>>> make//platform_ > >>>>>>>>>> files > >>>>>>>>>>>> in > >>>>>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are > defined > >>>>>>>> twice. > >>>>>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DAMD64 > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >>>>>>>> D_GNU_SOURCE > >>>>>>>>>> - > >>>>>>>>>>>>>>>> DAMD64 > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DIA32 > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >>>>>>>> D_GNU_SOURCE > >>>>>>>>>> - > >>>>>>>>>>>>>> DIA32 > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DIA64 - > >>>>>>>>>> DCC_INTERP > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >>>>>> DCC_INTERP - > >>>>>>>>>>>> DZERO - > >>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - > >>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS - > D_GNU_SOURCE - > >>>>>>>> DAMD64 > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS - > D_GNU_SOURCE - > >>>>>> DIA32 > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 - > DCC_INTERP > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP - > DZERO - > >>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - > >>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>>> runtime- > >>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are > any > >>>>>> further > >>>>>>>>>>>> issues, > >>>>>>>>>>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and > Coleen > >>>>>> in > >>>>>>>> this > >>>>>>>>>>>> new > >>>>>>>>>>>>>>>>>> webrev: > >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are > defined > >>>>>>>>>>>>>>>>>>> at the same time. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just > xxx. > >>>>>>>>>>>>>>>>>> This > >>>>>>>> kind > >>>>>>>>>> of > >>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the > Open > >>>>>>>> Aarch64 > >>>>>>>>>>>> port > >>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is > for the > >>>>>> Open > >>>>>>>>>> port > >>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I > wonder - > >>>>>>>>>>>>>>>>>> just > >>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be > restored? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >>>>>> Kim > >>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>>>>>>>>>>>>>>>> platform > >>>>>> files. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this > should > >>>>>> be > >>>>>>>>>> fixed > >>>>>>>>>>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do > just > >>>>>>>>>>>>>>>>>>>>> that. > >>>>>> :) > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as > the value > >>>>>>>> for > >>>>>>>>>> the > >>>>>>>>>>>>>> ifdef > >>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I > change > >>>>>>>>>>>>>>>>>>>>> that > >>>>>>>> value > >>>>>>>>>> to > >>>>>>>>>>>>>>>> match > >>>>>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will > lead to > >>>>>> other > >>>>>>>>>>>>>> problems > >>>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>>>>>>>> we also need that value the way it is currently > >>>>>>>>>>>>>>>>>>>>> defined. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm > >>>>>>>>>>>>>>>>>>>>> fresher. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Sorry but this really does need the > CPU_HEADER_H > >>>>>> macro. > >>>>>>>> In > >>>>>>>>>>>>>> general > >>>>>>>>>>>>>>>> you > >>>>>>>>>>>>>>>>>>>> can't just replace: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually > exclusive. > >>>>>>>>>>>>>>>>>>>> In our > >>>>>>>> case > >>>>>>>>>>>> ARM > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. > In > >>>>>> contrast > >>>>>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is > chosen > >>>>>> to > >>>>>>>>>>>>>> represent > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>> ; > >>>>>>>>>> Kim > >>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >>>>>> hotspot- > >>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>> platform > >>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as > it > >>>>>> appends > >>>>>>>>>> .hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >>>>>>>> CPU_HEADER_H, > >>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each > >>>>>>>>>>>>>>>>>>>>>>>>>> will be > >>>>>>>> used > >>>>>>>>>>>> only > >>>>>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I > >>>>>>>>>>>>>>>>>>>>>>>>>> should do > >>>>>> it > >>>>>>>> to > >>>>>>>>>> get > >>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch > names > >>>>>> need > >>>>>>>> not > >>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise > this > >>>>>> needs > >>>>>>>> to > >>>>>>>>>> be > >>>>>>>>>>>> an > >>>>>>>>>>>>>> if- > >>>>>>>>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they > are > >>>>>>>>>>>>>>>>>>>>>>>> set in > >>>>>>>>>>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>>>>> in the same statement as the > >>>>>> INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in > from > >>>>>> the > >>>>>>>>>> closed > >>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our > port. So > >>>>>> we > >>>>>>>> get > >>>>>>>>>>>> both > >>>>>>>>>>>>>>>>>> defined > >>>>>>>>>>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. > Trying to > >>>>>>>>>> understand > >>>>>>>>>>>>>> what > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is > intended to > >>>>>>>> be, > >>>>>>>>>> as > >>>>>>>>>>>> we > >>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the > >>>>>>>>>>>>>>>>>>>>>>> current > >>>>>>>>>> problem, > >>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>> ; > >>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > dev at openjdk.java.net; > >>>>>>>> hotspot- > >>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > including > >>>>>>>> platform > >>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, > Goetz wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more > >>>>>>>>>>>>>>>>>>>>>>>>>> detail! > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>> ; > >>>>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > dev at openjdk.java.net; > >>>>>>>>>> hotspot- > >>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > including > >>>>>>>>>> platform > >>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, > Goetz > >>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of > clarifications > >>>>>> and > >>>>>>>>>>>>>> comments > >>>>>>>>>>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> So the change from > HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common > arch > >>>>>>>> directory, > >>>>>>>>>> but > >>>>>>>>>>>> I > >>>>>>>>>>>>>>>> don't > >>>>>>>>>>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the > generated > >>>>>>>>>>>>>>>>>>>>>>>>>>> files. > >>>>>>>>>> (Sorry I > >>>>>>>>>>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see > what > >>>>>> needs > >>>>>>>> to > >>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>> changed > >>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I > send > >>>>>>>>>>>>>>>>>>>>>>>>>>> this > >>>>>> :).) > >>>>>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a > >>>>>>>>>>>>>>>>>>>>>>>>>> directory > >>>>>> that > >>>>>>>> has > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it > >>>>>>>>>>>>>>>>>>>>>>>>>> builds to > >>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more > _32/_64 > >>>>>>>>>> header > >>>>>>>>>>>>>> files if > >>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that > >>>>>>>>>>>>>>>>>>>>>>>>>>> dispatches > >>>>>>>>>>>> internally > >>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this > did > >>>>>>>>>>>>>>>>>>>>>>>>>> not > >>>>>>>> hold: > >>>>>>>>>>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there > anyways was > >>>>>> a > >>>>>>>>>>>> common > >>>>>>>>>>>>>> file > >>>>>>>>>>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick > to > >>>>>> avoid > >>>>>>>> this > >>>>>>>>>>>> kind > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>>>>>>>> #elif > defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, > pc); > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in > >>>>>>>> TARGET_SO... > >>>>>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should > be > >>>>>> moved > >>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can > simply be > >>>>>>>>>> elided > >>>>>>>>>>>>>> here ?? > >>>>>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, > which is > >>>>>> the > >>>>>>>>>>>>>> umbrella > >>>>>>>>>>>>>>>>>> header > >>>>>>>>>>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed > >>>>>>>>>>>>>>>>>>>>>>>>>> anyways. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as > it > >>>>>> appends > >>>>>>>>>> .hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >>>>>>>> CPU_HEADER_H, > >>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each > >>>>>>>>>>>>>>>>>>>>>>>>>> will be > >>>>>>>> used > >>>>>>>>>>>> only > >>>>>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I > >>>>>>>>>>>>>>>>>>>>>>>>>> should do > >>>>>> it > >>>>>>>> to > >>>>>>>>>> get > >>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch > names > >>>>>> need > >>>>>>>> not > >>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise > this > >>>>>> needs > >>>>>>>> to > >>>>>>>>>> be > >>>>>>>>>>>> an > >>>>>>>>>>>>>> if- > >>>>>>>>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of > >>>>>> WINDOWS? Is > >>>>>>>>>> that > >>>>>>>>>>>>>>>> coming > >>>>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I > defined > >>>>>>>>>>>> WINDOWS > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our > build is > >>>>>>>> defining > >>>>>>>>>> - > >>>>>>>>>>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS > instead. > >>>>>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by > WINDOWS, > >>>>>>>> but > >>>>>>>>>> not > >>>>>>>>>>>> in > >>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and > removed the > >>>>>>>>>> unused > >>>>>>>>>>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this > empty > >>>>>> file. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>> ; > >>>>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > dev at openjdk.java.net; > >>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> including > >>>>>>>>>>>> platform > >>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, > Goetz > >>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, > it's > >>>>>>>> working > >>>>>>>>>> on > >>>>>>>>>>>> all > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' > in > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>> macros > >>>>>>>>>>>> and > >>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the > name > >>>>>>>>>>>>>> construction > >>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in > >>>>>>>> macros.hpp. > >>>>>>>>>> But > >>>>>>>>>>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the > makefile, and > >>>>>> uses > >>>>>>>>>> the > >>>>>>>>>>>>>> very > >>>>>>>>>>>>>>>>>> same > >>>>>>>>>>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one > could > >>>>>>>> include > >>>>>>>>>>>> that > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail > and > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> am as > >>>>>>>> fine > >>>>>>>>>>>> with > >>>>>>>>>>>>>> your > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is > better is > >>>>>> that > >>>>>>>>>> the > >>>>>>>>>>>>>> linux=1 > >>>>>>>>>>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the > macros > >>>>>> should > >>>>>>>> be > >>>>>>>>>>>>>> upper > >>>>>>>>>>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >>>>>>>>>> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley > ; > >>>>>>>> hotspot- > >>>>>>>>>>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: > Simplify > >>>>>> including > >>>>>>>>>>>>>> platform > >>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, > Lindenmaier, > >>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that > these > >>>>>> macros > >>>>>>>> are > >>>>>>>>>>>> only > >>>>>>>>>>>>>>>> used > >>>>>>>>>>>>>>>>>>>> within > >>>>>>>>>>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code > everybody > >>>>>>>> needs > >>>>>>>>>> to > >>>>>>>>>>>>>>>>>> understand > >>>>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes.hpp > >>>>>>>> and > >>>>>>>>>>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for > cpu/os/os_cpu > >>>>>>>>>>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have to > >>>>>>>>>> spend > >>>>>>>>>>>> days > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and > posted > >>>>>> my > >>>>>>>>>>>> current > >>>>>>>>>>>>>>>>>> progress > >>>>>>>>>>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I > need to > >>>>>> do > >>>>>>>> is > >>>>>>>>>>>> adding > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about > the > >>>>>> includes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what > Volker > >>>>>>>>>>>> proposed > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the > email > >>>>>>>> thread > >>>>>>>>>> for > >>>>>>>>>>>>>> me; it > >>>>>>>>>>>>>>>>>> looks > >>>>>>>>>>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- > >>>>>> compiler- > >>>>>>>> dev > >>>>>>>>>> but > >>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the > compiler > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list > >>>>>>>> this > >>>>>>>>>>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details. > >>>>>> I've > >>>>>>>>>> only > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks > like it > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can > >>>>>>>> wait > >>>>>>>>>>>> until > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------- > ---------- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>> --- > >>>>>>>> --- > >>>>>>>>>> ---- > >>>>>>>>>>>> --- > >>>>>>>>>>>>>> ---- > >>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to > workaround > >>>>>> existing > >>>>>>>>>>>> #defines > >>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. > Detected so > >>>>>> far: > >>>>>>>>>>>> linux=1, > >>>>>>>>>>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making > the > >>>>>>>> leading > >>>>>>>>>>>>>>>> underscore > >>>>>>>>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, > e.g. in > >>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 > JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for > the > >>>>>>>> values. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be > written > >>>>>> as > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_header_stem(basename) > >>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants > brackets > >>>>>>>>>> instead > >>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for > example) > >>>>>> are > >>>>>>>>>>>> defined, > >>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But > note that > >>>>>>>>>>>> underscore > >>>>>>>>>>>>>>>>>>>> followed > >>>>>>>>>>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the > reserved word > >>>>>>>>>> pattern > >>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to > use > >>>>>>>> uppercase > >>>>>>>>>> for > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> macro > >>>>>>>>>>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about > that. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------- > ---------- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>> --- > >>>>>>>> --- > >>>>>>>>>> ---- > >>>>>>>>>>>> --- > >>>>>>>>>>>>>> ---- > >>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > From karen.kinnear at oracle.com Wed Jul 27 11:58:34 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Jul 2016 07:58:34 -0400 Subject: RFR: JDK-8162340: Better class stream parsing In-Reply-To: <1141a99d-ad1c-86f7-1f22-2c8ea39a6703@oracle.com> References: <2B62F4F7-674D-4558-935A-A721CB822AF8@oracle.com> <5f805e1a-6cb6-a58b-c13c-3d75176eda6c@oracle.com> <3218ED6D-4B9C-4C74-83A6-D9CD2DB88494@oracle.com> <1141a99d-ad1c-86f7-1f22-2c8ea39a6703@oracle.com> Message-ID: <0A632DB4-16D5-48C1-B098-807AFC5373EF@oracle.com> Many thanks. Karen > On Jul 26, 2016, at 10:36 PM, David Holmes wrote: > > On 27/07/2016 8:18 AM, Karen Kinnear wrote: >> I updated the web rev after all - with Coleen?s suggested changes and shortened new comment lines. >> >> http://cr.openjdk.java.net/~acorn/8162340.hs.3/webrev/ >> >> I will push once I hear from David. > > Looks good to me. Thanks for clearing up my confusion over Platform vs. System/Application loader. :) > > Thanks, > David > >> thanks all, >> Karen >> >>> On Jul 26, 2016, at 1:50 PM, Coleen Phillimore wrote: >>> >>> >>> Thanks! >>> Coleen >>> >>> On 7/26/16 1:31 PM, Karen Kinnear wrote: >>>> Coleen, >>>> >>>> Thank you for the reminder on this review - >>>> >>>>> On Jul 21, 2016, at 6:45 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>>>> >>>>> +// Handles unsafe_DefineAnonymousClass and redefineclasses >>>>> +// redefinedclasses do not add to the class hierarchy >>>>> >>>>> Can you change /redefineclasses/RedefineClasses/? We pattern match on this. >>>> Fixed. >>>>> Can you remove the additional blank line at @@ -1418,10 +1393,11 @@ >>>> Fixed the two additional blank lines - thank you for catching. >>>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/instanceKlass.cpp.udiff.html >>>>> >>>>> Since check_prohibited_package() is called from instanceKlass, and doesn't use any instance variables of either class, it should be a local static function defined in instanceKlass.cpp. >>>> Done. Made it private static for now. >>>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/src/share/vm/oops/symbol.hpp.udiff.html >>>>> >>>>> Awesome! I'm glad you found this comment to remove. >>>> thanks to Frederic. >>>>> Nobody's going to miss parsed_name. This is a nice change! >>>> I hoped you would like that :-) >>>> >>>> thanks for the review, >>>> Karen >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 7/21/16 1:23 PM, Karen Kinnear wrote: >>>>>> Please review: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8162340 >>>>>> >>>>>> http://cr.openjdk.java.net/~acorn/8162340.hs/webrev/ >>>>>> http://cr.openjdk.java.net/~acorn/8162340.jdk.test/webrev >>>>>> >>>>>> When moving the check from resolve_from_stream to set_package, I removed >>>>>> the no longer need parsed_class (!) which I should have cleaned up when >>>>>> tightening the placeholder table cleanup years ago. >>>>>> >>>>>> Tests run: >>>>>> 1. updated VMAnonymousClass test >>>>>> 2. jcks >>>>>> 3. rbt hs-nightly-runtime linux-x64 in progress >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> >>> >> From david.holmes at oracle.com Wed Jul 27 12:11:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 22:11:21 +1000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <5a852442473f4ba18ac4e5fa190fdf34@DEWDFE13DE09.global.corp.sap> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> <523ad277-d788-3967-3f5e-499c14062684@oracle.com> <5a852442473f4ba18ac4e5fa190fdf34@DEWDFE13DE09.global.corp.sap> Message-ID: <151d61bd-461e-6490-34bb-68affd8bac39@oracle.com> On 27/07/2016 7:40 PM, Lindenmaier, Goetz wrote: > Hi, > > I'm sorry, I messed this up. Thanks for looking after this. > In my first webrev, the bugID was correct, after that it's one off. > I don't know what happened. These things happen from time to time. > Should "8161258: [Win] Timer functionality is broken after JDK-8089563" > be reopened so that it gets a new bugID? No it was already closed. > Btw, why isn't jcheck catching this? jcheck only comes into play when the same bug ID is used with different changesets in a given repo. In this case the other bug is a FX bug and not in this repo. But the same could have happened if the bug had been fixed in jdk9/dev but not yet pulled down to jdk9/hs. Cheers, David > Best regards and sorry again, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 27. Juli 2016 03:46 >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >> >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L): 8161259: Simplify including platform files. >> >> On 27/07/2016 7:38 AM, Daniel D. Daugherty wrote: >>> I've made some manual updates to both bugs and will keep an eye >>> on JDK-8161258. As it goes through it's phases I'll try to make >>> the same updates to JDK-8161259. >> >> Thanks Dan - much appreciated. >> >> David >> >>> Dan >>> >>> >>> On 7/26/16 2:21 PM, David Holmes wrote: >>>> The patch for this used the wrong bug ID - 8161258 instead of 8161259. >>>> >>>> Not sure what I'm going to be able to do about that :( >>>> >>>> David >>>> ----- >>>> >>>> On 26/07/2016 11:12 AM, David Holmes wrote: >>>>> On 25/07/2016 3:01 PM, David Holmes wrote: >>>>>> This all looks good. Approval is now in place. Just waiting for final >>>>>> conformation this builds okay for Aarch64 folk. >>>>> >>>>> That confirmation was sent to compiler-dev so the changes have been >>>>> pushed. >>>>> >>>>> David >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>>> I see the typo was actually much bigger than I thought :) Presumably >>>>>>>> the >>>>>>> Well, I edited it some more ... this time I replaced the webrev >>>>>>> in-place, >>>>>>> webrev.05 is fixed now. >>>>>>> >>>>>>> I really should have an aarch64 machine :) >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 21. Juli 2016 12:00 >>>>>>>> To: Lindenmaier, Goetz ; Kim Barrett >>>>>>>> >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>> >>>>>>>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Copyright of register_definitions_x86.cpp is already fixed in >>>>>>>>> hs-comp, >>>>>>>>> I'll skip it to avoid merges. >>>>>>>> >>>>>>>> This isn't going into hs-comp so I don't know when the two will >>>>>>>> collide. >>>>>>>> I would deal with it anyway - I can just apply the patch without >>>>>>>> committing, deal with any merges, and then commit as you. >>>>>>>> >>>>>>>>> I fixed the others. New webrevs, also with Coleens fixes: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >> newPfmIncl/webrev.05/ >>>>>>>> >>>>>>>> I see the typo was actually much bigger than I thought :) Presumably >>>>>>>> the >>>>>>>> INLCUDE typo caused it to be missed by a global search replace. >>>>>>>> >>>>>>>>> I also did another zero build configured as follows: >>>>>>>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm- >>>>>>>> variants=zero >>>>>>>>> on linuxx86_64. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 21. Juli 2016 05:26 >>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>> >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>> dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>> >>>>>>>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>> newPfmIncl/webrev.04/ >>>>>>>>>>> >>>>>>>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in >>>>>>>>>> CompileJvm.gmk >>>>>>>>>>> and reverts the change to the aarch define in >>>>>>>>>>> vmStructs_jvmci.cpp. I >>>>>>>>>> documented >>>>>>>>>>> what I learned about the platform defines in macros.hpp. >>>>>>>>>> >>>>>>>>>> Thanks - much appreciated. Other than Coleen's typo (well >> spotted!) >>>>>>>>>> and >>>>>>>>>> the lingering _32 the only nit I have left is a handful of >>>>>>>>>> copyright >>>>>>>>>> updates: >>>>>>>>>> >>>>>>>>>> src/cpu/x86/vm/register_definitions_x86.cpp: >>>>>>>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: >>>>>>>>>> src/share/vm/runtime/semaphore.hpp: >>>>>>>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: >>>>>>>>>> src/cpu/ppc/vm/templateTable_ppc.hpp >>>>>>>>>> >>>>>>>>>> Then all we need is confirmation that all the open platforms that >>>>>>>>>> Oracle >>>>>>>>>> doesn't also build (aarch64 and Zero) build and run successfully >>>>>>>>>> after >>>>>>>>>> this change. >>>>>>>>>> >>>>>>>>>> I will sponsor this (in case that wasn't clear) but may have to >>>>>>>>>> delay it >>>>>>>>>> until after we sync up the hs forest with the CPU changes now in >>>>>>>>>> jdk9/dev. I will rebase and handle any merging if needed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>>>> >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. >>>>>>>>>>>> >>>>>>>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> OK, to get this through I will add >>>>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>> and revert this one and only place it needs to be used in the >>>>>>>>>>>> vmStructs_jvmci.cpp. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such >>>>>>>> cleanups >>>>>>>>>>>> should >>>>>>>>>>>>> not be in this change. >>>>>>>>>>>> >>>>>>>>>>>> I did not know they had a 64-bit C1 - interesting. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for doing the closed changes! >>>>>>>>>>>> >>>>>>>>>>>> You're welcome. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim >> Barrett >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> that's great what you are saying and just the design I would >>>>>>>>>>>>>>> expect! >>>>>>>>>>>>>>>> We did not want to have to >>>>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for >>>>>>>>>>>>>>>> "64-bit >>>>>>>> ARM" >>>>>>>>>> so >>>>>>>>>>>>>>>> we worked with the Open port to ensure that shared >> code >>>>>>>> guarded >>>>>>>>>> by >>>>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was >> used to >>>>>>>>>>>> identify >>>>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a >>>>>>>>>>>>>>>> handful of >>>>>>>>>>>> places >>>>>>>>>>>>>>>> that needed it. And sometimes we have to be careful and >>>>>>>>>>>>>>>> ensure >>>>>>>>>> that >>>>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think as a consequence the open AARCH port should >> define >>>>>>>>>>>>>>> ARM, >>>>>>>>>> too. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would not want to do this and certainly not as part of this >>>>>>>>>>>>>> change. >>>>>>>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, >>>>>>>>>>>>>> but not >>>>>>>>>>>>>> right now, please. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I checked the occurrences and only see three places where >> this >>>>>>>> would >>>>>>>>>>>> have >>>>>>>>>>>>>>> an effect and would have to be fixed somehow: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: >>>>>>>>>>>>>>> [610] #if defined(AARCH64) && >>>>>>>>>>>>>>> !defined(ARM) >>>>>>>>>>>>>>> ==> Would this break the closed port if defined? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 >>>>>>>>>>>>>> sources. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 >> was >>>>>>>> used) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: >>>>>>>>>>>>>>> load_item_force[253] #if !defined(ARM) && >>>>>>>>>>>>>>> !defined(E500V2) >>>>>>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: >>>>>>>>>>>>>>> [1154] #ifdef ARM >>>>>>>>>>>>>>> ==> Would this break the open port if defined? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think the open port has C1 so it would ignore the >> above >>>>>>>>>>>>>> files >>>>>>>>>>>>>> anyway. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> All the cases below are pointless. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>>>>>> defines, but >>>>>>>>>>>>>>>> keeping them so they can be used as include guards (or >> other >>>>>>>>>>>> conditional >>>>>>>>>>>>>>>> code) when needed, and where the macros are not >> suitable. >>>>>>>>>>>>>>> I think it's quite misleading to have two defines that are >> 99% >>>>>>>>>> equivalent. >>>>>>>>>>>>>>> If we really need a special case here, you should define - >>>>>>>>>> DARM_CLOSED >>>>>>>>>>>>>>> or the like in your closed port. Such a name would make >> clear >>>>>>>> what's >>>>>>>>>> the >>>>>>>>>>>>>>> issue. At least, only your closed port has this problem. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I really do not want to make any changes to this - ignoring >> the >>>>>>>> include >>>>>>>>>>>>>> macro changes everything we have is working perfectly fine >> just >>>>>>>>>>>>>> the >>>>>>>>>> way >>>>>>>>>>>>>> the defines are. So I don't want to see this change >> potentially >>>>>>>>>>>>>> break >>>>>>>>>>>>>> that through incidental changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not see having the following is a big issue: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>> - >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>> >>>>>>>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 >> port, and >>>>>>>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that >> define >>>>>>>>>> intend >>>>>>>>>>>> it to >>>>>>>>>>>>>> mean. It certainly is a lot better than interpreting what the >>>>>>>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this >> removes the >>>>>>>>>>>> need to >>>>>>>>>>>>>> perform some of the changes as noted above. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm preparing the review of the internal changes we need to >>>>>>>>>> accompany >>>>>>>>>>>> this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These should not break the open port if ARM gets defined, >>>>>>>>>>>>>>> or can >>>>>>>> be >>>>>>>>>>>> fixed >>>>>>>>>>>>>> easily. >>>>>>>>>>>>>>> --------------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>>>>>> print[1519] #elif defined(ARM) >>>>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os/linux/vm/os_linux.cpp: >>>>>>>>>>>>>>> dll_load[1796] #elif (defined ARM) >>>>>>>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) >>>>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/opto/matcher.cpp: >>>>>>>>>>>>>>> init_first_stack_mask[558] #ifdef ARM >>>>>>>>>>>>>>> ==> Should be ARM32 (Is under !LP64). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: >>>>>>>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == >>>>>>>>>>>>>>> cpu_register) >>>>>>>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == >>>>>>>>>>>>>>> cpu_register) >>>>>>>>>>>>>>> ==> Just an assertion. Will just relax the check if defined >>>>>>>>>>>>>>> in open >>>>>>>>>>>> AARCH64. >>>>>>>>>>>>>>> But maybe should be guarded by __SOFTFP__. >>>>>>>>>>>>>>> [70] #if defined(ARM) || >>>>>>>>>>>>>>> defined(AARCH64) || >>>>>>>>>>>>>> defined(PPC64) >>>>>>>>>>>>>>> ==> Fine: || >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: >>>>>>>>>>>>>>> [447] #if defined(SPARC) || >>>>>>>>>>>>>>> defined(ARM) || >>>>>>>>>>>>>> defined(PPC) || defined(AARCH64) >>>>>>>>>>>>>>> [537] #if defined(X86) || >>>>>>>>>>>>>>> defined(ARM) || >>>>>>>>>>>>>> defined(AARCH64) >>>>>>>>>>>>>>> ==> Fine: || >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: >>>>>>>>>>>>>>> defined[162] #if defined(IA32) || >>>>>>>>>>>>>>> defined(AMD64) || >>>>>>>>>>>>>> defined(ARM) >>>>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: >>>>>>>>>>>>>>> [1358] #if defined(IA32) || >>>>>>>>>>>>>>> defined(AMD64) || >>>>>>>>>>>>>> defined(ARM) >>>>>>>>>>>>>>> ==> Just defines a method which would be unused, should >> be >>>>>>>>>>>>>>> fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These are in code not used in the open AARCH64 port: >>>>>>>>>>>>>>> -------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>>>>>> [215] #elif defined(ARM) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** >> os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: >>>>>>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>>>>>> [102] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** >> os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: >>>>>>>>>>>>>>> [31] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** share/vm/utilities/macros.hpp: >>>>>>>>>>>>>>> [434] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: >>>>>>>>>>>>>>> dll_load[1508] #elif (defined ARM) >>>>>>>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, >>>>>>>>>>>>>>> __powerpc__, >>>>>>>>>> ARM, >>>>>>>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: >>>>>>>>>>>>>>> dll_load[1725] #elif (defined ARM) >>>>>>>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, >>>>>>>>>>>>>>> __powerpc__, >>>>>>>>>> ARM, >>>>>>>>>>>>>> ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: >>>>>>>>>>>>>>> store[164] #if !defined(ARM) && >>>>>>>>>>>>>>> !defined(M68K) >>>>>>>>>>>>>>> store_ptr[171] #if !defined(ARM) && >>>>>>>>>>>>>>> !defined(M68K) >>>>>>>>>>>>>>> add[178] #ifdef ARM >>>>>>>>>>>>>>> add_ptr[190] #ifdef ARM >>>>>>>>>>>>>>> xchg[230] #ifdef ARM >>>>>>>>>>>>>>> xchg_ptr[253] #ifdef ARM >>>>>>>>>>>>>>> cmpxchg[275] #ifdef ARM >>>>>>>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: >>>>>>>>>>>>>>> add[172] #ifdef ARM >>>>>>>>>>>>>>> add_ptr[184] #ifdef ARM >>>>>>>>>>>>>>> xchg[224] #ifdef ARM >>>>>>>>>>>>>>> xchg_ptr[247] #ifdef ARM >>>>>>>>>>>>>>> cmpxchg[269] #ifdef ARM >>>>>>>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Kim >>>>>>>> Barrett >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and >> s390. >>>>>>>>>>>>>>>>> (Parisc is gone, puh!). >>>>>>>>>>>>>>>>> We basically patch all the shared changes onto the >> sources >>>>>>>>>>>>>>>>> after >>>>>>>>>>>>>>>>> getting them via our licensee channel. >>>>>>>>>>>>>>>>> I think you should fix your closed port not to re-use the >>>>>>>>>>>>>>>>> names of >>>>>>>>>> the >>>>>>>>>>>>>>>>> main openJdk platforms! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not >> want to >>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for >>>>>>>>>>>>>>>> "64-bit >>>>>>>> ARM" >>>>>>>>>> so >>>>>>>>>>>>>>>> we worked with the Open port to ensure that shared >> code >>>>>>>> guarded >>>>>>>>>> by >>>>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was >> used to >>>>>>>>>>>> identify >>>>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a >>>>>>>>>>>>>>>> handful of >>>>>>>>>>>> places >>>>>>>>>>>>>>>> that needed it. And sometimes we have to be careful and >>>>>>>>>>>>>>>> ensure >>>>>>>>>> that >>>>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This has all been working quite nicely, as the include >> guards >>>>>>>>>>>>>>>> used, >>>>>>>> for >>>>>>>>>>>>>>>> example, TARGET_ARCH_AARCH64 and >> TARGET_ARCH_ARM - >>>>>>>> which >>>>>>>>>>>> are >>>>>>>>>>>>>>>> never >>>>>>>>>>>>>>>> defined at the same time (derived from >>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH). >>>>>>>>>>>>>> But >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> current changes remove those unique defines and, >> before the >>>>>>>>>>>> HEADER_H >>>>>>>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and >> ARM as >>>>>>>>>>>> include >>>>>>>>>>>>>>>> guards, and that doesn't work as they are not mutually >>>>>>>>>>>>>>>> exclusive. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those >>>>>>>>>>>>>>>> defines, but >>>>>>>>>>>>>>>> keeping them so they can be used as include guards (or >> other >>>>>>>>>>>> conditional >>>>>>>>>>>>>>>> code) when needed, and where the macros are not >> suitable. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have no idea what hardware is addressed by your >> closed >>>>>>>>>>>>>>>>> ports, >>>>>>>>>>>>>>>>> nor how you merge sources. >>>>>>>>>>>>>>>>> Is there also a port that sets >>>>>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>>>>> -DARM32 >>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To fix this either you define >>>>>>>>>>>>>>>>> #if defined(ARM) && defined(_LP64) >>>>>>>>>>>>>>>>> #define ARM64 >>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line. >>>>>>>>>>>>>>>>> Then you replace all >>>>>>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) >>>>>>>>>>>>>>>>> or maybe it suffices altogether f you replace >>>>>>>>>>>>>>>>> #ifdef AARCH64 >>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For ppc, when we did the port we knew (and that's all >> we >>>>>>>>>>>>>>>>> knew) >>>>>>>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these >>>>>>>>>>>>>>>>> macros >>>>>>>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two >> for >>>>>>>>>>>> LP64/!LP64 >>>>>>>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the >> closed >>>>>>>>>>>>>>>>> port >>>>>>>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared >> for >>>>>>>>>>>>>>>>> both >>>>>>>>>>>> (PPC). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But I don't think it is necessary to do any further changes >>>>>>>>>>>>>>>>> now, >>>>>>>>>>>> assuming >>>>>>>>>>>>>>>>> my change works for you as I adapted it. So we're all set I >>>>>>>>>>>>>>>>> guess! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM >>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; Kim >>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform >>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just >> xxx. >>>>>>>>>>>>>>>>>>>> This >>>>>>>>>> kind >>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the >> Open >>>>>>>>>> Aarch64 >>>>>>>>>>>>>> port >>>>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is >> for the >>>>>>>> Open >>>>>>>>>>>> port >>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I >> wonder - >>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be >> restored? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. >>>>>>>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle >> that? >>>>>>>> You >>>>>>>>>>>> have >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> check every AARCH change by RedHat against your >> closed >>>>>>>> port? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The sources for the two ports are distinct so the only >>>>>>>>>>>>>>>>>> place we >>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> have a convention is in shared code that has CPU >> specific >>>>>>>>>>>>>>>>>> stuff >>>>>>>> and >>>>>>>>>> in >>>>>>>>>>>>>>>>>> the build files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The open Aarch64 port sets (among others): >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_aarch64 >>>>>>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> the closed port sets >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_arm >>>>>>>>>>>>>>>>>> -DARM >>>>>>>>>>>>>>>>>> -DAARCH64 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that >> distinguishes >>>>>>>>>>>>>>>>>> them. >>>>>>>>>>>>>>>> Whenever >>>>>>>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it >> is/was >>>>>>>>>> referring >>>>>>>>>>>> to >>>>>>>>>>>>>>>> our >>>>>>>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the >> open >>>>>>>>>> Aarch64 >>>>>>>>>>>>>> port. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same >> position. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We need to keep a clear distinction. Using the >>>>>>>>>>>>>>>>>> combination of >>>>>>>>>>>> AARCH64 >>>>>>>>>>>>>>>>>> and ARM is not so clear. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You could easily have similar issues with other port >> groups >>>>>>>>>>>>>>>>>> - eg >>>>>>>>>> ppc64 >>>>>>>>>>>>>>>>>> vs ppc32 vs ppcle. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came >> up >>>>>>>> recently, >>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> before that it sure was equivalent. And it still is the >>>>>>>>>>>>>>>>>>> case for >>>>>>>>>>>> openJDK. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Below output is grepped out of the >>>>>>>> make//platform_ >>>>>>>>>>>> files >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are >> defined >>>>>>>>>> twice. >>>>>>>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >> DAMD64 >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>>>>>> D_GNU_SOURCE >>>>>>>>>>>> - >>>>>>>>>>>>>>>>>> DAMD64 >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >> DIA32 >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - >>>>>>>>>> D_GNU_SOURCE >>>>>>>>>>>> - >>>>>>>>>>>>>>>> DIA32 >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >> DIA64 - >>>>>>>>>>>> DCC_INTERP >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >> DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >> DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - >>>>>>>> DCC_INTERP - >>>>>>>>>>>>>> DZERO - >>>>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS - >> D_GNU_SOURCE - >>>>>>>>>> DAMD64 >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS - >> D_GNU_SOURCE - >>>>>>>> DIA32 >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 - >> DCC_INTERP >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP - >> DZERO - >>>>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - >>>>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM >>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; Kim >>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >> platform >>>>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are >> any >>>>>>>> further >>>>>>>>>>>>>> issues, >>>>>>>>>>>>>>>>>>>> but the incremental changes look okay. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I added macros for C headers: >>>>>>>>>>>>>>>>>>>>> CPU_HEADER_H() etc. >>>>>>>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and >> Coleen >>>>>>>> in >>>>>>>>>> this >>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>> newPfmIncl/webrev.03/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are >> defined >>>>>>>>>>>>>>>>>>>>> at the same time. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to >>>>>>>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just >> xxx. >>>>>>>>>>>>>>>>>>>> This >>>>>>>>>> kind >>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that the >> Open >>>>>>>>>> Aarch64 >>>>>>>>>>>>>> port >>>>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is >> for the >>>>>>>> Open >>>>>>>>>>>> port >>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I >> wonder - >>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be >> restored? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> My incremental changes are in this patch: >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>> From: David Holmes >> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM >>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >> ; >>>>>>>> Kim >>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>>>>>>>>>>>>>>>> platform >>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: >>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz >> wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this >> should >>>>>>>> be >>>>>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>>>>> in the closed code. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do >> just >>>>>>>>>>>>>>>>>>>>>>> that. >>>>>>>> :) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as >> the value >>>>>>>>>> for >>>>>>>>>>>> the >>>>>>>>>>>>>>>> ifdef >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I >> change >>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>> value >>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> match >>>>>>>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will >> lead to >>>>>>>> other >>>>>>>>>>>>>>>> problems >>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>> we also need that value the way it is currently >>>>>>>>>>>>>>>>>>>>>>> defined. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm >>>>>>>>>>>>>>>>>>>>>>> fresher. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Sorry but this really does need the >> CPU_HEADER_H >>>>>>>> macro. >>>>>>>>>> In >>>>>>>>>>>>>>>> general >>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>> can't just replace: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> #ifdef abc >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually >> exclusive. >>>>>>>>>>>>>>>>>>>>>> In our >>>>>>>>>> case >>>>>>>>>>>>>> ARM >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. >> In >>>>>>>> contrast >>>>>>>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is >> chosen >>>>>>>> to >>>>>>>>>>>>>>>> represent >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> architecture in this context. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>> ; >>>>>>>>>>>> Kim >>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; >>>>>>>> hotspot- >>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including >>>>>>>> platform >>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz >> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as >> it >>>>>>>> appends >>>>>>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>>>>>> CPU_HEADER_H, >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each >>>>>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>> used >>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>>>>>> should do >>>>>>>> it >>>>>>>>>> to >>>>>>>>>>>> get >>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch >> names >>>>>>>> need >>>>>>>>>> not >>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise >> this >>>>>>>> needs >>>>>>>>>> to >>>>>>>>>>>> be >>>>>>>>>>>>>> an >>>>>>>>>>>>>>>> if- >>>>>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they >> are >>>>>>>>>>>>>>>>>>>>>>>>>> set in >>>>>>>>>>>>>>>>>>>> CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>>>> in the same statement as the >>>>>>>> INCLUDE_SUFFIX_CPU: >>>>>>>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in >> from >>>>>>>> the >>>>>>>>>>>> closed >>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our >> port. So >>>>>>>> we >>>>>>>>>> get >>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>>>> defined >>>>>>>>>>>>>>>>>>>>>>>>> and try to include two platform files. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. >> Trying to >>>>>>>>>>>> understand >>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is >> intended to >>>>>>>>>> be, >>>>>>>>>>>> as >>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the >>>>>>>>>>>>>>>>>>>>>>>>> current >>>>>>>>>>>> problem, >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>> changing it may break something else. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 >>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>> ; >>>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- >> dev at openjdk.java.net; >>>>>>>>>> hotspot- >>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >> including >>>>>>>>>> platform >>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, >> Goetz wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more >>>>>>>>>>>>>>>>>>>>>>>>>>>> detail! >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>> ; >>>>>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- >> dev at openjdk.java.net; >>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >> including >>>>>>>>>>>> platform >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, >> Goetz >>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- >>>>>>>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of >> clarifications >>>>>>>> and >>>>>>>>>>>>>>>> comments >>>>>>>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> So the change from >> HOTSPOT_TARGET_CPU to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only >>>>>>>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common >> arch >>>>>>>>>> directory, >>>>>>>>>>>> but >>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the >> generated >>>>>>>>>>>>>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>> (Sorry I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see >> what >>>>>>>> needs >>>>>>>>>> to >>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I >> send >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>> :).) >>>>>>>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a >>>>>>>>>>>>>>>>>>>>>>>>>>>> directory >>>>>>>> that >>>>>>>>>> has >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> word size >>>>>>>>>>>>>>>>>>>>>>>>>>>> in it's name: >>>>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release >>>>>>>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it >>>>>>>>>>>>>>>>>>>>>>>>>>>> builds to >>>>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, >>>>>>>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more >> _32/_64 >>>>>>>>>>>> header >>>>>>>>>>>>>>>> files if >>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>>>> read it >>>>>>>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dispatches >>>>>>>>>>>>>> internally >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this >> did >>>>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>> hold: >>>>>>>>>>>>>>>>>>>>>>>>>>>> stubRoutines >>>>>>>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there >> anyways was >>>>>>>> a >>>>>>>>>>>>>> common >>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>>>>>>>> that was included in both. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick >> to >>>>>>>> avoid >>>>>>>>>> this >>>>>>>>>>>>>> kind >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #elif >> defined(TARGET_OS_FAMILY_solaris) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ie something like: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, >> pc); >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? :) >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in >>>>>>>>>> TARGET_SO... >>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should >> be >>>>>>>> moved >>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can >> simply be >>>>>>>>>>>> elided >>>>>>>>>>>>>>>> here ?? >>>>>>>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, >> which is >>>>>>>> the >>>>>>>>>>>>>>>> umbrella >>>>>>>>>>>>>>>>>>>> header >>>>>>>>>>>>>>>>>>>>>>>>>>>> for all the platform files. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> be: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 >>>>>>>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed >>>>>>>>>>>>>>>>>>>>>>>>>>>> anyways. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as >> it >>>>>>>> appends >>>>>>>>>>>> .hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg >>>>>>>>>> CPU_HEADER_H, >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>> appends.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each >>>>>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>> used >>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>> once. >>>>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I >>>>>>>>>>>>>>>>>>>>>>>>>>>> should do >>>>>>>> it >>>>>>>>>> to >>>>>>>>>>>> get >>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch >> names >>>>>>>> need >>>>>>>>>> not >>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>> mutually >>>>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise >> this >>>>>>>> needs >>>>>>>>>> to >>>>>>>>>>>> be >>>>>>>>>>>>>> an >>>>>>>>>>>>>>>> if- >>>>>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #endif >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of >>>>>>>> WINDOWS? Is >>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> coming >>>>>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> compiler itself? >>>>>>>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I >> defined >>>>>>>>>>>>>> WINDOWS >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our >> build is >>>>>>>>>> defining >>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>> D_WINDOWS >>>>>>>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, >>>>>>>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS >> instead. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by >> WINDOWS, >>>>>>>>>> but >>>>>>>>>>>> not >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>>>> change. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> also typo: littel >>>>>>>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and >> removed the >>>>>>>>>>>> unused >>>>>>>>>>>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this >> empty >>>>>>>> file. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes >>>>>>>>>>>>>> [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>> ; >>>>>>>>>>>>>>>> Kim >>>>>>>>>>>>>>>>>>>>>> Barrett >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- >> dev at openjdk.java.net; >>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> including >>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, >> Goetz >>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, >> it's >>>>>>>>>> working >>>>>>>>>>>> on >>>>>>>>>>>>>> all >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' >> in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>> macros >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the >> name >>>>>>>>>>>>>>>> construction >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in >>>>>>>>>> macros.hpp. >>>>>>>>>>>> But >>>>>>>>>>>>>>>>>>>>>> constructing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the >> makefile, and >>>>>>>> uses >>>>>>>>>>>> the >>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>>>>>>> string >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one >> could >>>>>>>>>> include >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> macro, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> too.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail >> and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> am as >>>>>>>>>> fine >>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is >> better is >>>>>>>> that >>>>>>>>>>>> the >>>>>>>>>>>>>>>> linux=1 >>>>>>>>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the >> macros >>>>>>>> should >>>>>>>>>> be >>>>>>>>>>>>>>>> upper >>>>>>>>>>>>>>>>>> case? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett >>>>>>>>>>>> [mailto:kim.barrett at oracle.com] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley >> ; >>>>>>>>>> hotspot- >>>>>>>>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot- >> runtime- >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: >> Simplify >>>>>>>> including >>>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, >> Lindenmaier, >>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that >> these >>>>>>>> macros >>>>>>>>>> are >>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>>>>>>>> 20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> lines >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code >> everybody >>>>>>>>>> needs >>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes.hpp >>>>>>>>>> and >>>>>>>>>>>>>>>> expands to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for >> cpu/os/os_cpu >>>>>>>>>>>>>>>>>>>> and .hpp/.inline.hpp. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>> spend >>>>>>>>>>>>>> days >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and >> posted >>>>>>>> my >>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>>>>> progress >>>>>>>>>>>>>>>>>>>>>>>>>>> claiming >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I >> need to >>>>>>>> do >>>>>>>>>> is >>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> #includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about >> the >>>>>>>> includes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what >> Volker >>>>>>>>>>>>>> proposed >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- >>>>>>>>>>>>>>>>>> dev/2016- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the >> email >>>>>>>>>> thread >>>>>>>>>>>> for >>>>>>>>>>>>>>>> me; it >>>>>>>>>>>>>>>>>>>> looks >>>>>>>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to hotspot- >>>>>>>> compiler- >>>>>>>>>> dev >>>>>>>>>>>> but >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> hotspot- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> runtime- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the >> compiler >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list >>>>>>>>>> this >>>>>>>>>>>>>>>> morning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details. >>>>>>>> I've >>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks >> like it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>> wait >>>>>>>>>>>>>> until >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------- >> ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> --- >>>>>>>>>> --- >>>>>>>>>>>> ---- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> ---- >>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to >> workaround >>>>>>>> existing >>>>>>>>>>>>>> #defines >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>> spoil >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. >> Detected so >>>>>>>> far: >>>>>>>>>>>>>> linux=1, >>>>>>>>>>>>>>>>>>>> sparc=1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making >> the >>>>>>>>>> leading >>>>>>>>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, >> e.g. in >>>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 >> JVM_CFLAGS_TARGET_DEFINES += \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - >>>>>>>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) >>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) >>>>>>>>>>>>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for >> the >>>>>>>>>> values. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be >> written >>>>>>>> as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> os_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> os_cpu_header_stem(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> PASTE_TOKENS(INCLUDE_SUFFIX_OS, >>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> XSTR(cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> os_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> os_cpu_header(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define >> os_cpu_header_inline(basename) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants >> brackets >>>>>>>>>>>> instead >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for >> example) >>>>>>>> are >>>>>>>>>>>>>> defined, >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>>>>>>>> true >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But >> note that >>>>>>>>>>>>>> underscore >>>>>>>>>>>>>>>>>>>>>> followed >>>>>>>>>>>>>>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the >> reserved word >>>>>>>>>>>> pattern >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> C/C++. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to >> use >>>>>>>>>> uppercase >>>>>>>>>>>> for >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> macro >>>>>>>>>>>>>>>>>>>>>>>>>>> names. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about >> that. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------- >> ---------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> --- >>>>>>>>>> --- >>>>>>>>>>>> ---- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> ---- >>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> From goetz.lindenmaier at sap.com Wed Jul 27 12:25:03 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Jul 2016 12:25:03 +0000 Subject: RFR(L): 8161259: Simplify including platform files. In-Reply-To: <151d61bd-461e-6490-34bb-68affd8bac39@oracle.com> References: <7a2949d4312d4ee987db1fc34c5e5f5b@DEWDFE13DE09.global.corp.sap> <702a92a0d18546618afdce722387d8e4@DEWDFE13DE09.global.corp.sap> <61c521c8-b071-852a-26e8-adc620d24270@oracle.com> <919daaf5-012a-4dfb-9f68-e576fb409926@oracle.com> <1ad0cb0a225d4a4291fd1ad587d18a9a@DEWDFE13DE09.global.corp.sap> <694cf0c7-5ff1-c759-ef98-f3ce94a984b3@oracle.com> <243bbfe5f0434a279555d25c96457d8b@DEWDFE13DE09.global.corp.sap> <34549584-3823-b8fd-4c39-fbf197af86ec@oracle.com> <58ce1e6c-b19e-4c41-4492-4406c8c96a46@oracle.com> <523ad277-d788-3967-3f5e-499c14062684@oracle.com> <5a852442473f4ba18ac4e5fa190fdf34@DEWDFE13DE09.global.corp.sap> <151d61bd-461e-6490-34bb-68affd8bac39@oracle.com> Message-ID: <8da4b4f118af49e48cc741046b0c21c1@DEWDFE13DE09.global.corp.sap> Hi David, I understand it can not check whether the bug is open or closed already. But it could compare the synopsis. Once again, thanks for fixing this ... Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 27. Juli 2016 14:11 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com > Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(L): 8161259: Simplify including platform files. > > On 27/07/2016 7:40 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I'm sorry, I messed this up. Thanks for looking after this. > > In my first webrev, the bugID was correct, after that it's one off. > > I don't know what happened. > > These things happen from time to time. > > > Should "8161258: [Win] Timer functionality is broken after JDK-8089563" > > be reopened so that it gets a new bugID? > > No it was already closed. > > > Btw, why isn't jcheck catching this? > > jcheck only comes into play when the same bug ID is used with different > changesets in a given repo. In this case the other bug is a FX bug and > not in this repo. But the same could have happened if the bug had been > fixed in jdk9/dev but not yet pulled down to jdk9/hs. > > Cheers, > David > > > Best regards and sorry again, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 27. Juli 2016 03:46 > >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >> > >> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >> > >> On 27/07/2016 7:38 AM, Daniel D. Daugherty wrote: > >>> I've made some manual updates to both bugs and will keep an eye > >>> on JDK-8161258. As it goes through it's phases I'll try to make > >>> the same updates to JDK-8161259. > >> > >> Thanks Dan - much appreciated. > >> > >> David > >> > >>> Dan > >>> > >>> > >>> On 7/26/16 2:21 PM, David Holmes wrote: > >>>> The patch for this used the wrong bug ID - 8161258 instead of 8161259. > >>>> > >>>> Not sure what I'm going to be able to do about that :( > >>>> > >>>> David > >>>> ----- > >>>> > >>>> On 26/07/2016 11:12 AM, David Holmes wrote: > >>>>> On 25/07/2016 3:01 PM, David Holmes wrote: > >>>>>> This all looks good. Approval is now in place. Just waiting for final > >>>>>> conformation this builds okay for Aarch64 folk. > >>>>> > >>>>> That confirmation was sent to compiler-dev so the changes have been > >>>>> pushed. > >>>>> > >>>>> David > >>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>> On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> > >>>>>>>> I see the typo was actually much bigger than I thought :) > Presumably > >>>>>>>> the > >>>>>>> Well, I edited it some more ... this time I replaced the webrev > >>>>>>> in-place, > >>>>>>> webrev.05 is fixed now. > >>>>>>> > >>>>>>> I really should have an aarch64 machine :) > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Donnerstag, 21. Juli 2016 12:00 > >>>>>>>> To: Lindenmaier, Goetz ; Kim > Barrett > >>>>>>>> > >>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>> > >>>>>>>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>> Copyright of register_definitions_x86.cpp is already fixed in > >>>>>>>>> hs-comp, > >>>>>>>>> I'll skip it to avoid merges. > >>>>>>>> > >>>>>>>> This isn't going into hs-comp so I don't know when the two will > >>>>>>>> collide. > >>>>>>>> I would deal with it anyway - I can just apply the patch without > >>>>>>>> committing, deal with any merges, and then commit as you. > >>>>>>>> > >>>>>>>>> I fixed the others. New webrevs, also with Coleens fixes: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >> newPfmIncl/webrev.05/ > >>>>>>>> > >>>>>>>> I see the typo was actually much bigger than I thought :) > Presumably > >>>>>>>> the > >>>>>>>> INLCUDE typo caused it to be missed by a global search replace. > >>>>>>>> > >>>>>>>>> I also did another zero build configured as follows: > >>>>>>>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with- > jvm- > >>>>>>>> variants=zero > >>>>>>>>> on linuxx86_64. > >>>>>>>> > >>>>>>>> Thanks. > >>>>>>>> > >>>>>>>> David > >>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Donnerstag, 21. Juli 2016 05:26 > >>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>> > >>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > >>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>> > >>>>>>>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi > >>>>>>>>>>> > >>>>>>>>>>> New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>> newPfmIncl/webrev.04/ > >>>>>>>>>>> > >>>>>>>>>>> It re-adds - > DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in > >>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>> and reverts the change to the aarch define in > >>>>>>>>>>> vmStructs_jvmci.cpp. I > >>>>>>>>>> documented > >>>>>>>>>>> what I learned about the platform defines in macros.hpp. > >>>>>>>>>> > >>>>>>>>>> Thanks - much appreciated. Other than Coleen's typo (well > >> spotted!) > >>>>>>>>>> and > >>>>>>>>>> the lingering _32 the only nit I have left is a handful of > >>>>>>>>>> copyright > >>>>>>>>>> updates: > >>>>>>>>>> > >>>>>>>>>> src/cpu/x86/vm/register_definitions_x86.cpp: > >>>>>>>>>> > src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > >>>>>>>>>> src/share/vm/runtime/semaphore.hpp: > >>>>>>>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp: > >>>>>>>>>> src/cpu/ppc/vm/templateTable_ppc.hpp > >>>>>>>>>> > >>>>>>>>>> Then all we need is confirmation that all the open platforms > that > >>>>>>>>>> Oracle > >>>>>>>>>> doesn't also build (aarch64 and Zero) build and run successfully > >>>>>>>>>> after > >>>>>>>>>> this change. > >>>>>>>>>> > >>>>>>>>>> I will sponsor this (in case that wasn't clear) but may have to > >>>>>>>>>> delay it > >>>>>>>>>> until after we sync up the hs forest with the CPU changes now > in > >>>>>>>>>> jdk9/dev. I will rebase and handle any merging if needed. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> ----- > >>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05 > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Kim > >> Barrett > >>>>>>>>>>>> > >>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > runtime- > >>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files. > >>>>>>>>>>>> > >>>>>>>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>> > >>>>>>>>>>>>> OK, to get this through I will add > >>>>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>> and revert this one and only place it needs to be used in > the > >>>>>>>>>>>> vmStructs_jvmci.cpp. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks. > >>>>>>>>>>>> > >>>>>>>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, > such > >>>>>>>> cleanups > >>>>>>>>>>>> should > >>>>>>>>>>>>> not be in this change. > >>>>>>>>>>>> > >>>>>>>>>>>> I did not know they had a 64-bit C1 - interesting. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks for doing the closed changes! > >>>>>>>>>>>> > >>>>>>>>>>>> You're welcome. > >>>>>>>>>>>> > >>>>>>>>>>>> Cheers, > >>>>>>>>>>>> David > >>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13 > >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Kim > >> Barrett > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>>>> files. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> that's great what you are saying and just the design I > would > >>>>>>>>>>>>>>> expect! > >>>>>>>>>>>>>>>> We did not want to have to > >>>>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for > >>>>>>>>>>>>>>>> "64-bit > >>>>>>>> ARM" > >>>>>>>>>> so > >>>>>>>>>>>>>>>> we worked with the Open port to ensure that shared > >> code > >>>>>>>> guarded > >>>>>>>>>> by > >>>>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM > was > >> used to > >>>>>>>>>>>> identify > >>>>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a > >>>>>>>>>>>>>>>> handful of > >>>>>>>>>>>> places > >>>>>>>>>>>>>>>> that needed it. And sometimes we have to be careful > and > >>>>>>>>>>>>>>>> ensure > >>>>>>>>>> that > >>>>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think as a consequence the open AARCH port should > >> define > >>>>>>>>>>>>>>> ARM, > >>>>>>>>>> too. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I would not want to do this and certainly not as part of this > >>>>>>>>>>>>>> change. > >>>>>>>>>>>>>> If/when the Aarch32 port arrives we may have to revisit > this, > >>>>>>>>>>>>>> but not > >>>>>>>>>>>>>> right now, please. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I checked the occurrences and only see three places > where > >> this > >>>>>>>> would > >>>>>>>>>>>> have > >>>>>>>>>>>>>>> an effect and would have to be fixed somehow: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp: > >>>>>>>>>>>>>>> [610] #if defined(AARCH64) && > >>>>>>>>>>>>>>> !defined(ARM) > >>>>>>>>>>>>>>> ==> Would this break the closed port if defined? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 > >>>>>>>>>>>>>> sources. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 > >> was > >>>>>>>> used) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp: > >>>>>>>>>>>>>>> load_item_force[253] #if !defined(ARM) && > >>>>>>>>>>>>>>> !defined(E500V2) > >>>>>>>>>>>>>>> ==> Would this break the open port if defined? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp: > >>>>>>>>>>>>>>> [1154] #ifdef ARM > >>>>>>>>>>>>>>> ==> Would this break the open port if defined? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I don't think the open port has C1 so it would ignore the > >> above > >>>>>>>>>>>>>> files > >>>>>>>>>>>>>> anyway. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> All the cases below are pointless. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those > >>>>>>>>>>>>>>>> defines, but > >>>>>>>>>>>>>>>> keeping them so they can be used as include guards (or > >> other > >>>>>>>>>>>> conditional > >>>>>>>>>>>>>>>> code) when needed, and where the macros are not > >> suitable. > >>>>>>>>>>>>>>> I think it's quite misleading to have two defines that are > >> 99% > >>>>>>>>>> equivalent. > >>>>>>>>>>>>>>> If we really need a special case here, you should define - > >>>>>>>>>> DARM_CLOSED > >>>>>>>>>>>>>>> or the like in your closed port. Such a name would make > >> clear > >>>>>>>> what's > >>>>>>>>>> the > >>>>>>>>>>>>>>> issue. At least, only your closed port has this problem. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I really do not want to make any changes to this - ignoring > >> the > >>>>>>>> include > >>>>>>>>>>>>>> macro changes everything we have is working perfectly > fine > >> just > >>>>>>>>>>>>>> the > >>>>>>>>>> way > >>>>>>>>>>>>>> the defines are. So I don't want to see this change > >> potentially > >>>>>>>>>>>>>> break > >>>>>>>>>>>>>> that through incidental changes. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I do not see having the following is a big issue: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>> - > >> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open > ARMv8 > >> port, and > >>>>>>>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that > >> define > >>>>>>>>>> intend > >>>>>>>>>>>> it to > >>>>>>>>>>>>>> mean. It certainly is a lot better than interpreting what the > >>>>>>>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this > >> removes the > >>>>>>>>>>>> need to > >>>>>>>>>>>>>> perform some of the changes as noted above. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm preparing the review of the internal changes we need > to > >>>>>>>>>> accompany > >>>>>>>>>>>> this. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> David > >>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> These should not break the open port if ARM gets > defined, > >>>>>>>>>>>>>>> or can > >>>>>>>> be > >>>>>>>>>>>> fixed > >>>>>>>>>>>>>> easily. > >>>>>>>>>>>>>>> --------------------------------------------------------- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>>>>>>>>>> print[1519] #elif defined(ARM) > >>>>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** os/linux/vm/os_linux.cpp: > >>>>>>>>>>>>>>> dll_load[1796] #elif (defined ARM) > >>>>>>>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM) > >>>>>>>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/opto/matcher.cpp: > >>>>>>>>>>>>>>> init_first_stack_mask[558] #ifdef ARM > >>>>>>>>>>>>>>> ==> Should be ARM32 (Is under !LP64). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIR.cpp: > >>>>>>>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == > >>>>>>>>>>>>>>> cpu_register) > >>>>>>>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == > >>>>>>>>>>>>>>> cpu_register) > >>>>>>>>>>>>>>> ==> Just an assertion. Will just relax the check if defined > >>>>>>>>>>>>>>> in open > >>>>>>>>>>>> AARCH64. > >>>>>>>>>>>>>>> But maybe should be guarded by __SOFTFP__. > >>>>>>>>>>>>>>> [70] #if defined(ARM) || > >>>>>>>>>>>>>>> defined(AARCH64) || > >>>>>>>>>>>>>> defined(PPC64) > >>>>>>>>>>>>>>> ==> Fine: || > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/c1/c1_LIR.hpp: > >>>>>>>>>>>>>>> [447] #if defined(SPARC) || > >>>>>>>>>>>>>>> defined(ARM) || > >>>>>>>>>>>>>> defined(PPC) || defined(AARCH64) > >>>>>>>>>>>>>>> [537] #if defined(X86) || > >>>>>>>>>>>>>>> defined(ARM) || > >>>>>>>>>>>>>> defined(AARCH64) > >>>>>>>>>>>>>>> ==> Fine: || > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp: > >>>>>>>>>>>>>>> defined[162] #if defined(IA32) || > >>>>>>>>>>>>>>> defined(AMD64) || > >>>>>>>>>>>>>> defined(ARM) > >>>>>>>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp: > >>>>>>>>>>>>>>> [1358] #if defined(IA32) || > >>>>>>>>>>>>>>> defined(AMD64) || > >>>>>>>>>>>>>> defined(ARM) > >>>>>>>>>>>>>>> ==> Just defines a method which would be unused, > should > >> be > >>>>>>>>>>>>>>> fine. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> These are in code not used in the open AARCH64 port: > >>>>>>>>>>>>>>> -------------------------------------------------- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>>>>>>>>>> [215] #elif defined(ARM) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>>>>>>>>>> [102] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** > >> os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp: > >>>>>>>>>>>>>>> [31] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** > os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>>>>>>>>>> [102] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** > >> os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp: > >>>>>>>>>>>>>>> [31] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** share/vm/utilities/macros.hpp: > >>>>>>>>>>>>>>> [434] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** os/bsd/vm/os_bsd.cpp: > >>>>>>>>>>>>>>> dll_load[1508] #elif (defined ARM) > >>>>>>>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, > >>>>>>>>>>>>>>> __powerpc__, > >>>>>>>>>> ARM, > >>>>>>>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** os/solaris/vm/os_solaris.cpp: > >>>>>>>>>>>>>>> dll_load[1725] #elif (defined ARM) > >>>>>>>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, > >>>>>>>>>>>>>>> __powerpc__, > >>>>>>>>>> ARM, > >>>>>>>>>>>>>> ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp: > >>>>>>>>>>>>>>> store[164] #if !defined(ARM) && > >>>>>>>>>>>>>>> !defined(M68K) > >>>>>>>>>>>>>>> store_ptr[171] #if !defined(ARM) && > >>>>>>>>>>>>>>> !defined(M68K) > >>>>>>>>>>>>>>> add[178] #ifdef ARM > >>>>>>>>>>>>>>> add_ptr[190] #ifdef ARM > >>>>>>>>>>>>>>> xchg[230] #ifdef ARM > >>>>>>>>>>>>>>> xchg_ptr[253] #ifdef ARM > >>>>>>>>>>>>>>> cmpxchg[275] #ifdef ARM > >>>>>>>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *** > os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp: > >>>>>>>>>>>>>>> add[172] #ifdef ARM > >>>>>>>>>>>>>>> add_ptr[184] #ifdef ARM > >>>>>>>>>>>>>>> xchg[224] #ifdef ARM > >>>>>>>>>>>>>>> xchg_ptr[247] #ifdef ARM > >>>>>>>>>>>>>>> cmpxchg[269] #ifdef ARM > >>>>>>>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59 > >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > ; > >> Kim > >>>>>>>> Barrett > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform > >>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and > >> s390. > >>>>>>>>>>>>>>>>> (Parisc is gone, puh!). > >>>>>>>>>>>>>>>>> We basically patch all the shared changes onto the > >> sources > >>>>>>>>>>>>>>>>> after > >>>>>>>>>>>>>>>>> getting them via our licensee channel. > >>>>>>>>>>>>>>>>> I think you should fix your closed port not to re-use > the > >>>>>>>>>>>>>>>>> names of > >>>>>>>>>> the > >>>>>>>>>>>>>>>>> main openJdk platforms! > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did > not > >> want to > >>>>>>>>>> have > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>> pollute the shared sources with two sets of ifdefs for > >>>>>>>>>>>>>>>> "64-bit > >>>>>>>> ARM" > >>>>>>>>>> so > >>>>>>>>>>>>>>>> we worked with the Open port to ensure that shared > >> code > >>>>>>>> guarded > >>>>>>>>>> by > >>>>>>>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM > was > >> used to > >>>>>>>>>>>> identify > >>>>>>>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a > >>>>>>>>>>>>>>>> handful of > >>>>>>>>>>>> places > >>>>>>>>>>>>>>>> that needed it. And sometimes we have to be careful > and > >>>>>>>>>>>>>>>> ensure > >>>>>>>>>> that > >>>>>>>>>>>>>>>> ifdef chains check AARCH64 before they check ARM. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This has all been working quite nicely, as the include > >> guards > >>>>>>>>>>>>>>>> used, > >>>>>>>> for > >>>>>>>>>>>>>>>> example, TARGET_ARCH_AARCH64 and > >> TARGET_ARCH_ARM - > >>>>>>>> which > >>>>>>>>>>>> are > >>>>>>>>>>>>>>>> never > >>>>>>>>>>>>>>>> defined at the same time (derived from > >>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH). > >>>>>>>>>>>>>> But > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> current changes remove those unique defines and, > >> before the > >>>>>>>>>>>> HEADER_H > >>>>>>>>>>>>>>>> forms were introduced, tried to use simple AARCH64 > and > >> ARM as > >>>>>>>>>>>> include > >>>>>>>>>>>>>>>> guards, and that doesn't work as they are not mutually > >>>>>>>>>>>>>>>> exclusive. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> So what I'm suggesting is just not getting rid of those > >>>>>>>>>>>>>>>> defines, but > >>>>>>>>>>>>>>>> keeping them so they can be used as include guards (or > >> other > >>>>>>>>>>>> conditional > >>>>>>>>>>>>>>>> code) when needed, and where the macros are not > >> suitable. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I have no idea what hardware is addressed by your > >> closed > >>>>>>>>>>>>>>>>> ports, > >>>>>>>>>>>>>>>>> nor how you merge sources. > >>>>>>>>>>>>>>>>> Is there also a port that sets > >>>>>>>>>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>>>>>>>>> -DARM > >>>>>>>>>>>>>>>>> -DARM32 > >>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> To fix this either you define > >>>>>>>>>>>>>>>>> #if defined(ARM) && defined(_LP64) > >>>>>>>>>>>>>>>>> #define ARM64 > >>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command > line. > >>>>>>>>>>>>>>>>> Then you replace all > >>>>>>>>>>>>>>>>> #ifdef AARCH64 > >>>>>>>>>>>>>>>>> by > >>>>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64) > >>>>>>>>>>>>>>>>> or maybe it suffices altogether f you replace > >>>>>>>>>>>>>>>>> #ifdef AARCH64 > >>>>>>>>>>>>>>>>> by > >>>>>>>>>>>>>>>>> #if defined(AARCH64) || defined(ARM) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> For ppc, when we did the port we knew (and that's all > >> we > >>>>>>>>>>>>>>>>> knew) > >>>>>>>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these > >>>>>>>>>>>>>>>>> macros > >>>>>>>>>>>>>>>>> as on x86, where there is one for the arch (X86) and > two > >> for > >>>>>>>>>>>> LP64/!LP64 > >>>>>>>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the > >> closed > >>>>>>>>>>>>>>>>> port > >>>>>>>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and > shared > >> for > >>>>>>>>>>>>>>>>> both > >>>>>>>>>>>> (PPC). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> But I don't think it is necessary to do any further > changes > >>>>>>>>>>>>>>>>> now, > >>>>>>>>>>>> assuming > >>>>>>>>>>>>>>>>> my change works for you as I adapted it. So we're all > set I > >>>>>>>>>>>>>>>>> guess! > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>> From: David Holmes > [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM > >>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; Kim > >>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > hotspot- > >> runtime- > >>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > platform > >>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just > >> xxx. > >>>>>>>>>>>>>>>>>>>> This > >>>>>>>>>> kind > >>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that > the > >> Open > >>>>>>>>>> Aarch64 > >>>>>>>>>>>>>> port > >>>>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is > >> for the > >>>>>>>> Open > >>>>>>>>>>>> port > >>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I > >> wonder - > >>>>>>>>>>>>>>>>>>>> just > >>>>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be > >> restored? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx. > >>>>>>>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you > handle > >> that? > >>>>>>>> You > >>>>>>>>>>>> have > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>> check every AARCH change by RedHat against your > >> closed > >>>>>>>> port? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> The sources for the two ports are distinct so the only > >>>>>>>>>>>>>>>>>> place we > >>>>>>>>>> have > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> have a convention is in shared code that has CPU > >> specific > >>>>>>>>>>>>>>>>>> stuff > >>>>>>>> and > >>>>>>>>>> in > >>>>>>>>>>>>>>>>>> the build files. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> The open Aarch64 port sets (among others): > >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_aarch64 > >>>>>>>>>>>>>>>>>> -DAARCH64 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> the closed port sets > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_arm > >>>>>>>>>>>>>>>>>> -DARM > >>>>>>>>>>>>>>>>>> -DAARCH64 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that > >> distinguishes > >>>>>>>>>>>>>>>>>> them. > >>>>>>>>>>>>>>>> Whenever > >>>>>>>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it > >> is/was > >>>>>>>>>> referring > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>> our > >>>>>>>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to > the > >> open > >>>>>>>>>> Aarch64 > >>>>>>>>>>>>>> port. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the > same > >> position. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> We need to keep a clear distinction. Using the > >>>>>>>>>>>>>>>>>> combination of > >>>>>>>>>>>> AARCH64 > >>>>>>>>>>>>>>>>>> and ARM is not so clear. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> You could easily have similar issues with other port > >> groups > >>>>>>>>>>>>>>>>>> - eg > >>>>>>>>>> ppc64 > >>>>>>>>>>>>>>>>>> vs ppc32 vs ppcle. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I don't know about the closed stuff, but aarch > came > >> up > >>>>>>>> recently, > >>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>> before that it sure was equivalent. And it still is the > >>>>>>>>>>>>>>>>>>> case for > >>>>>>>>>>>> openJDK. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Below output is grepped out of the > >>>>>>>> make//platform_ > >>>>>>>>>>>> files > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are > >> defined > >>>>>>>>>> twice. > >>>>>>>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64 > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >> DAMD64 > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >>>>>>>>>> D_GNU_SOURCE > >>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>> DAMD64 > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >> DIA32 > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS - > >>>>>>>>>> D_GNU_SOURCE > >>>>>>>>>>>> - > >>>>>>>>>>>>>>>> DIA32 > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >> DIA64 - > >>>>>>>>>>>> DCC_INTERP > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >> DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >> DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE - > >>>>>>>> DCC_INTERP - > >>>>>>>>>>>>>> DZERO - > >>>>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - > >>>>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS - > >> D_GNU_SOURCE - > >>>>>>>>>> DAMD64 > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS - > >> D_GNU_SOURCE - > >>>>>>>> DIA32 > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 - > >> DCC_INTERP > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64 > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP > - > >> DZERO - > >>>>>>>>>>>>>>>>>> D at ZERO_ARCHDEF@ - > >>>>>>>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\" > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64 > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64 > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32 > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32 > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC > >>>>>>>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM > >>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; Kim > >>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >> platform > >>>>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there > are > >> any > >>>>>>>> further > >>>>>>>>>>>>>> issues, > >>>>>>>>>>>>>>>>>>>> but the incremental changes look okay. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz > wrote: > >>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I added macros for C headers: > >>>>>>>>>>>>>>>>>>>>> CPU_HEADER_H() etc. > >>>>>>>>>>>>>>>>>>>>> and fixed the other issues mentioned by David > and > >> Coleen > >>>>>>>> in > >>>>>>>>>> this > >>>>>>>>>>>>>> new > >>>>>>>>>>>>>>>>>>>> webrev: > >>>>>>>>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>> newPfmIncl/webrev.03/ > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM > are > >> defined > >>>>>>>>>>>>>>>>>>>>> at the same time. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to > >>>>>>>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM) > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just > >> xxx. > >>>>>>>>>>>>>>>>>>>> This > >>>>>>>>>> kind > >>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> workaround is obscure - you have to know that > the > >> Open > >>>>>>>>>> Aarch64 > >>>>>>>>>>>>>> port > >>>>>>>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is > >> for the > >>>>>>>> Open > >>>>>>>>>>>> port > >>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I > >> wonder - > >>>>>>>>>>>>>>>>>>>> just > >>>>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be > >> restored? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> My incremental changes are in this patch: > >>>>>>>>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>>>> > newPfmIncl/webrev.03/incremental_changes.patch > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM > >>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >> ; > >>>>>>>> Kim > >>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; > >> hotspot- > >>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including > >>>>>>>>>>>>>>>>>>>>>> platform > >>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote: > >>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz > >> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually > this > >> should > >>>>>>>> be > >>>>>>>>>>>> fixed > >>>>>>>>>>>>>>>>>>>>>>>> in the closed code. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to > do > >> just > >>>>>>>>>>>>>>>>>>>>>>> that. > >>>>>>>> :) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as > >> the value > >>>>>>>>>> for > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>> ifdef > >>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I > >> change > >>>>>>>>>>>>>>>>>>>>>>> that > >>>>>>>>>> value > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> match > >>>>>>>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will > >> lead to > >>>>>>>> other > >>>>>>>>>>>>>>>> problems > >>>>>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>>>>>>>>>> we also need that value the way it is currently > >>>>>>>>>>>>>>>>>>>>>>> defined. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm > >>>>>>>>>>>>>>>>>>>>>>> fresher. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Sorry but this really does need the > >> CPU_HEADER_H > >>>>>>>> macro. > >>>>>>>>>> In > >>>>>>>>>>>>>>>> general > >>>>>>>>>>>>>>>>>> you > >>>>>>>>>>>>>>>>>>>>>> can't just replace: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> #ifdef abc > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually > >> exclusive. > >>>>>>>>>>>>>>>>>>>>>> In our > >>>>>>>>>> case > >>>>>>>>>>>>>> ARM > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> AARCH64 are both defined and are both > needed. > >> In > >>>>>>>> contrast > >>>>>>>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" > is > >> chosen > >>>>>>>> to > >>>>>>>>>>>>>>>> represent > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> architecture in this context. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13 > >>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>> ; > >>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > dev at openjdk.java.net; > >>>>>>>> hotspot- > >>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > including > >>>>>>>> platform > >>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, > Goetz > >> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, > as > >> it > >>>>>>>> appends > >>>>>>>>>>>> .hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >>>>>>>>>> CPU_HEADER_H, > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and > each > >>>>>>>>>>>>>>>>>>>>>>>>>>>> will be > >>>>>>>>>> used > >>>>>>>>>>>>>> only > >>>>>>>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I > >>>>>>>>>>>>>>>>>>>>>>>>>>>> should do > >>>>>>>> it > >>>>>>>>>> to > >>>>>>>>>>>> get > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch > >> names > >>>>>>>> need > >>>>>>>>>> not > >>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. > Otherwise > >> this > >>>>>>>> needs > >>>>>>>>>> to > >>>>>>>>>>>> be > >>>>>>>>>>>>>> an > >>>>>>>>>>>>>>>> if- > >>>>>>>>>>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they > >> are > >>>>>>>>>>>>>>>>>>>>>>>>>> set in > >>>>>>>>>>>>>>>>>>>> CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>>>>>>> in the same statement as the > >>>>>>>> INCLUDE_SUFFIX_CPU: > >>>>>>>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE) > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming > in > >> from > >>>>>>>> the > >>>>>>>>>>>> closed > >>>>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our > >> port. So > >>>>>>>> we > >>>>>>>>>> get > >>>>>>>>>>>>>> both > >>>>>>>>>>>>>>>>>>>> defined > >>>>>>>>>>>>>>>>>>>>>>>>> and try to include two platform files. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. > >> Trying to > >>>>>>>>>>>> understand > >>>>>>>>>>>>>>>> what > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is > >> intended to > >>>>>>>>>> be, > >>>>>>>>>>>> as > >>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is > the > >>>>>>>>>>>>>>>>>>>>>>>>> current > >>>>>>>>>>>> problem, > >>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>>>> changing it may break something else. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06 > >>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>> ; > >>>>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > >> dev at openjdk.java.net; > >>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > >> including > >>>>>>>>>> platform > >>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, > >> Goetz wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in > more > >>>>>>>>>>>>>>>>>>>>>>>>>>>> detail! > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>> ; > >>>>>>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > >> dev at openjdk.java.net; > >>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify > >> including > >>>>>>>>>>>> platform > >>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this! > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, > >> Goetz > >>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259- > >>>>>>>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of > >> clarifications > >>>>>>>> and > >>>>>>>>>>>>>>>> comments > >>>>>>>>>>>>>>>>>>>>>> below. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> So the change from > >> HOTSPOT_TARGET_CPU to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common > >> arch > >>>>>>>>>> directory, > >>>>>>>>>>>> but > >>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>> don't > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the > >> generated > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>> (Sorry I > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> haven't had > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and > see > >> what > >>>>>>>> needs > >>>>>>>>>> to > >>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>> changed > >>>>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I > >> send > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this > >>>>>>>> :).) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a > >>>>>>>>>>>>>>>>>>>>>>>>>>>> directory > >>>>>>>> that > >>>>>>>>>> has > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>> word size > >>>>>>>>>>>>>>>>>>>>>>>>>>>> in it's name: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release > >>>>>>>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it > >>>>>>>>>>>>>>>>>>>>>>>>>>>> builds to > >>>>>>>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no > more > >> _32/_64 > >>>>>>>>>>>> header > >>>>>>>>>>>>>>>> files if > >>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> read it > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> dispatches > >>>>>>>>>>>>>> internally > >>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where > this > >> did > >>>>>>>>>>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>> hold: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> stubRoutines > >>>>>>>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there > >> anyways was > >>>>>>>> a > >>>>>>>>>>>>>> common > >>>>>>>>>>>>>>>> file > >>>>>>>>>>>>>>>>>>>>>>>>>>>> that was included in both. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar > trick > >> to > >>>>>>>> avoid > >>>>>>>>>> this > >>>>>>>>>>>>>> kind > >>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #elif > >> defined(TARGET_OS_FAMILY_solaris) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc); > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ie something like: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > SUB(TARGET_OS)::ucontext_set_pc(ctx, > >> pc); > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? :) > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string > in > >>>>>>>>>> TARGET_SO... > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation > should > >> be > >>>>>>>> moved > >>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can > >> simply be > >>>>>>>>>>>> elided > >>>>>>>>>>>>>>>> here ?? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, > >> which is > >>>>>>>> the > >>>>>>>>>>>>>>>> umbrella > >>>>>>>>>>>>>>>>>>>> header > >>>>>>>>>>>>>>>>>>>>>>>>>>>> for all the platform files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > src/share/vm/jvmci/jvmciRuntime.cpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Shouldn't: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> be: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64 > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed > >>>>>>>>>>>>>>>>>>>>>>>>>>>> anyways. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, > as > >> it > >>>>>>>> appends > >>>>>>>>>>>> .hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg > >>>>>>>>>> CPU_HEADER_H, > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>> appends.h > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and > each > >>>>>>>>>>>>>>>>>>>>>>>>>>>> will be > >>>>>>>>>> used > >>>>>>>>>>>>>> only > >>>>>>>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I > >>>>>>>>>>>>>>>>>>>>>>>>>>>> should do > >>>>>>>> it > >>>>>>>>>> to > >>>>>>>>>>>> get > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>>>> similar everywhere. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch > >> names > >>>>>>>> need > >>>>>>>>>> not > >>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>> mutually > >>>>>>>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. > Otherwise > >> this > >>>>>>>> needs > >>>>>>>>>> to > >>>>>>>>>>>> be > >>>>>>>>>>>>>> an > >>>>>>>>>>>>>>>> if- > >>>>>>>>>>>>>>>>>>>> else > >>>>>>>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-) > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include > to: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> #endif > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Fixed. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of > >>>>>>>> WINDOWS? Is > >>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>> coming > >>>>>>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> compiler itself? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I > >> defined > >>>>>>>>>>>>>> WINDOWS > >>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our > >> build is > >>>>>>>>>> defining > >>>>>>>>>>>> - > >>>>>>>>>>>>>>>>>>>>>> D_WINDOWS > >>>>>>>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS > >> instead. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by > >> WINDOWS, > >>>>>>>>>> but > >>>>>>>>>>>> not > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>>>>>>>>>>>>> change. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> also typo: littel > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and > >> removed the > >>>>>>>>>>>> unused > >>>>>>>>>>>>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this > >> empty > >>>>>>>> file. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes > >>>>>>>>>>>>>> [mailto:david.holmes at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>>>> ; > >>>>>>>>>>>>>>>> Kim > >>>>>>>>>>>>>>>>>>>>>> Barrett > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler- > >> dev at openjdk.java.net; > >>>>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: > Simplify > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> including > >>>>>>>>>>>>>> platform > >>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, > Lindenmaier, > >> Goetz > >>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the > macros, > >> it's > >>>>>>>>>> working > >>>>>>>>>>>> on > >>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> platforms > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can build. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the > '_' > >> in > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>> macros > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of > the > >> name > >>>>>>>>>>>>>>>> construction > >>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are > in > >>>>>>>>>> macros.hpp. > >>>>>>>>>>>> But > >>>>>>>>>>>>>>>>>>>>>> constructing > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the > >> makefile, and > >>>>>>>> uses > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>> very > >>>>>>>>>>>>>>>>>>>> same > >>>>>>>>>>>>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', > one > >> could > >>>>>>>>>> include > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> macro, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> too.) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail > >> and > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> am as > >>>>>>>>>> fine > >>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>> your > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is > >> better is > >>>>>>>> that > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>> linux=1 > >>>>>>>>>>>>>>>>>>>> etc > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the > >> macros > >>>>>>>> should > >>>>>>>>>> be > >>>>>>>>>>>>>>>> upper > >>>>>>>>>>>>>>>>>> case? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett > >>>>>>>>>>>> [mailto:kim.barrett at oracle.com] > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 > 23:20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley > >> ; > >>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>> compiler- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot- > >> runtime- > >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: > >> Simplify > >>>>>>>> including > >>>>>>>>>>>>>>>> platform > >>>>>>>>>>>>>>>>>>>> files. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, > >> Lindenmaier, > >>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that > >> these > >>>>>>>> macros > >>>>>>>>>> are > >>>>>>>>>>>>>> only > >>>>>>>>>>>>>>>>>> used > >>>>>>>>>>>>>>>>>>>>>> within > >>>>>>>>>>>>>>>>>>>>>>>>> 20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> lines > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code > >> everybody > >>>>>>>>>> needs > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> understand > >>>>>>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes.hpp > >>>>>>>>>> and > >>>>>>>>>>>>>>>> expands to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for > >> cpu/os/os_cpu > >>>>>>>>>>>>>>>>>>>> and .hpp/.inline.hpp. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I > don't > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have to > >>>>>>>>>>>> spend > >>>>>>>>>>>>>> days > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB(). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, > and > >> posted > >>>>>>>> my > >>>>>>>>>>>>>> current > >>>>>>>>>>>>>>>>>>>> progress > >>>>>>>>>>>>>>>>>>>>>>>>>>> claiming > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I > >> need to > >>>>>>>> do > >>>>>>>>>> is > >>>>>>>>>>>>>> adding > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> #includes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about > >> the > >>>>>>>> includes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of > what > >> Volker > >>>>>>>>>>>>>> proposed > >>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot- > >>>>>>>>>>>>>>>>>> dev/2016- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to > the > >> email > >>>>>>>>>> thread > >>>>>>>>>>>> for > >>>>>>>>>>>>>>>> me; it > >>>>>>>>>>>>>>>>>>>> looks > >>>>>>>>>>>>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew?s replies went to > hotspot- > >>>>>>>> compiler- > >>>>>>>>>> dev > >>>>>>>>>>>> but > >>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>> hotspot- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> runtime- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dev, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the > >> compiler > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list > >>>>>>>>>> this > >>>>>>>>>>>>>>>> morning. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details. > >>>>>>>> I've > >>>>>>>>>>>> only > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks > >> like it > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can > >>>>>>>>>> wait > >>>>>>>>>>>>>> until > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------------------------- > --- > >> ---------- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> ---- > >>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>> ---- > >>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > src/share/vm/utilities/macros.hpp > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to > >> workaround > >>>>>>>> existing > >>>>>>>>>>>>>> #defines > >>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>> spoil > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. > >> Detected so > >>>>>>>> far: > >>>>>>>>>>>>>> linux=1, > >>>>>>>>>>>>>>>>>>>> sparc=1. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by > making > >> the > >>>>>>>>>> leading > >>>>>>>>>>>>>>>>>> underscore > >>>>>>>>>>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for > INCLUDE_SUFFIX_*, > >> e.g. in > >>>>>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 > >> JVM_CFLAGS_TARGET_DEFINES += \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 - > >>>>>>>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) > >>>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 - > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH) > >>>>>>>>>>>>>>>>>>>>>>>>>>> \ > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" > for > >> the > >>>>>>>>>> values. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can > be > >> written > >>>>>>>> as > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> os_header_stem(basename) > >>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> os_cpu_header_stem(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> PASTE_TOKENS(INCLUDE_SUFFIX_OS, > >>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> XSTR(cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> XSTR(cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > XSTR(os_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> os_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> XSTR(os_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> os_cpu_header(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> XSTR(os_cpu_header_stem(basename).hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define > >> os_cpu_header_inline(basename) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used... > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system > wants > >> brackets > >>>>>>>>>>>> instead > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for > >> example) > >>>>>>>> are > >>>>>>>>>>>>>> defined, > >>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that's > >>>>>>>>>>>>>>>>>>>>>>>>> true > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But > >> note that > >>>>>>>>>>>>>> underscore > >>>>>>>>>>>>>>>>>>>>>> followed > >>>>>>>>>>>>>>>>>>>>>>>>> by a > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the > >> reserved word > >>>>>>>>>>>> pattern > >>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> C/C++. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to > >> use > >>>>>>>>>> uppercase > >>>>>>>>>>>> for > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> macro > >>>>>>>>>>>>>>>>>>>>>>>>>>> names. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think > about > >> that. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------------------------- > --- > >> ---------- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> --- > >>>>>>>>>> --- > >>>>>>>>>>>> ---- > >>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>> ---- > >>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>> From frederic.parain at oracle.com Wed Jul 27 13:21:13 2016 From: frederic.parain at oracle.com (frederic parain) Date: Wed, 27 Jul 2016 09:21:13 -0400 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <579822B9.4040700@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> Message-ID: <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> Hi Jerry, On 26/07/2016 22:55, Gerald Thornbrugh wrote: > Hi David, >> Hi Jerry, >> >> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>> Hi Everyone, >>> >>> I would like to have the following change reviewed: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>> >>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>> >>> >>> The stack size for this test needs to be increased to 384K for some >>> platforms. >> >> Is there a specific reason we set -Xss in the first place instead of >> just taking the platform defaults? If the platform stack settings >> change this test may need updating again. > > It was my understand (maybe incorrectly) that setting -Xss was an > attempt to limit the memory and time > resources the test takes. Using the smallest stack size allowable will > allocate less memory and reduce the > amount of time the test takes. Since I think Fred wrote the test he > would know better than I would. > > Fred, what is the reason behind specifying "-Xss" for this test? I'm not the author of this test, but I can try to contribute my two cents. I'm not seeing any particular reason to limit the stack size to 320KB other than reducing time and resources required for this test. Looking at the test history, Dmitry did the current version of the test, but the "-Xss320k" argument was already there before Dmitry re-wrote the test to fix 8042155. So it looks like a relic from old code for which the rational has been lost. Regarding the test, limiting the stack size looks a good idea to avoid wasting too much time and resources during testing. However, I'm seeing to reason to make the stack size "as small as possible". A 1MB stack size could already provide efficient improvement while avoiding platform dependent stack size constraint (and I'll be cursed for this by next generations of HotSpot developer as a 1MB limitation could become completely unjustified in the future). Fred > I have thought about the test harness setting an environment variable > and/or a java property to the correct > minimum values for "-Xss" depending upon the architecture the test is > running on. The tests could then use > the value to start each test. That way each test could be tailored for > the specific architecture. After looking into > this it looks the implementation would be significant and would be > outside the scope of this bug fix. > > Thanks, > > Jerry >> >> Thanks, >> David >> >>> My fix for JDK-8081770 https://bugs.openjdk.java.net/browse/JDK-8081770 >>> moved the functionality >>> from the testme.sh script to exeinvoke.c so the dependency for a local >>> compiler could be removed. >>> Because of this the stack size change needs to be applied to exeinvoke.c >>> file instead of the testme.sh file. >>> >>> Please let me know if you have any questions or concerns. >>> >>> Thanks, >>> >>> Jerry > From gerald.thornbrugh at oracle.com Wed Jul 27 13:48:35 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 27 Jul 2016 07:48:35 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> Message-ID: <5798BBB3.6000805@oracle.com> Hi Fred, Thanks for the information. How does everyone feel about implementing Fred's suggestion of a stack size of 1MB? As Fred states this not a complete fix but it would provide relief from this issue for the foreseeable future. Thanks, Jerry > Hi Jerry, > > On 26/07/2016 22:55, Gerald Thornbrugh wrote: >> Hi David, >>> Hi Jerry, >>> >>> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>>> Hi Everyone, >>>> >>>> I would like to have the following change reviewed: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>>> >>>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>>> >>>> >>>> The stack size for this test needs to be increased to 384K for some >>>> platforms. >>> >>> Is there a specific reason we set -Xss in the first place instead of >>> just taking the platform defaults? If the platform stack settings >>> change this test may need updating again. >> >> It was my understand (maybe incorrectly) that setting -Xss was an >> attempt to limit the memory and time >> resources the test takes. Using the smallest stack size allowable will >> allocate less memory and reduce the >> amount of time the test takes. Since I think Fred wrote the test he >> would know better than I would. >> >> Fred, what is the reason behind specifying "-Xss" for this test? > > I'm not the author of this test, but I can try to contribute my > two cents. > > I'm not seeing any particular reason to limit the stack size to > 320KB other than reducing time and resources required for this > test. > > Looking at the test history, Dmitry did the current version of the > test, but the "-Xss320k" argument was already there before Dmitry > re-wrote the test to fix 8042155. So it looks like a relic from > old code for which the rational has been lost. > > Regarding the test, limiting the stack size looks a good idea to > avoid wasting too much time and resources during testing. However, > I'm seeing to reason to make the stack size "as small as possible". > A 1MB stack size could already provide efficient improvement while > avoiding platform dependent stack size constraint (and I'll be > cursed for this by next generations of HotSpot developer as a > 1MB limitation could become completely unjustified in the future). > > Fred > >> I have thought about the test harness setting an environment variable >> and/or a java property to the correct >> minimum values for "-Xss" depending upon the architecture the test is >> running on. The tests could then use >> the value to start each test. That way each test could be tailored for >> the specific architecture. After looking into >> this it looks the implementation would be significant and would be >> outside the scope of this bug fix. >> >> Thanks, >> >> Jerry >>> >>> Thanks, >>> David >>> >>>> My fix for JDK-8081770 >>>> https://bugs.openjdk.java.net/browse/JDK-8081770 >>>> moved the functionality >>>> from the testme.sh script to exeinvoke.c so the dependency for a local >>>> compiler could be removed. >>>> Because of this the stack size change needs to be applied to >>>> exeinvoke.c >>>> file instead of the testme.sh file. >>>> >>>> Please let me know if you have any questions or concerns. >>>> >>>> Thanks, >>>> >>>> Jerry >> From daniel.daugherty at oracle.com Wed Jul 27 14:48:28 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Jul 2016 08:48:28 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <5798BBB3.6000805@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> <5798BBB3.6000805@oracle.com> Message-ID: <05f2960d-fad7-7c2c-bd7c-3cdbb53dcb7f@oracle.com> On 7/27/16 7:48 AM, Gerald Thornbrugh wrote: > Hi Fred, > > Thanks for the information. > > How does everyone feel about implementing Fred's suggestion of a stack > size of 1MB? > As Fred states this not a complete fix but it would provide relief > from this issue for the > foreseeable future. Fred, sorry for the mis-attribution. I'm not sure why I thought you wrote the test... Short answer: I'm good with changing the test to use a stack size of 1MB. Longer answer (with some historical bits): Looks like Dmitry S. created the current version of the test with this changeset: $ hg log -v -r 16432bba405a changeset: 6482:16432bba405a user: dsamersoff date: Thu May 22 13:22:09 2014 -0700 files: test/runtime/6929067/T.java test/runtime/6929067/Test6929067.sh test/runtime/6929067/invoke.c test/runtime/InitialThreadOverflow/DoOverflow.java test/runtime/InitialThreadOverflow/invoke.c test/runtime/InitialThreadOverflow/testme.sh test/runtime/StackGuardPages/DoOverflow.java test/runtime/StackGuardPages/invoke.c test/runtime/StackGuardPages/testme.sh description: 8042155: [TESTBUG] Tests for stack guard pages have to be cleaned up Summary: Tests for 6929067 and 8009062 should be composed to single test that provide better testing for stack guard pages behaviour Reviewed-by: coleenp, dcubed, dsimms Sifting through the history implies that the test for 8009062 was derived from 6929067; both tests have -Xss320k in their invoke.c implementations. $ hg log -v -r 3b3d12e645e7 changeset: 1320:3b3d12e645e7 parent: 1292:12d91eb0f579 user: coleenp date: Fri Mar 12 10:42:16 2010 -0500 files: src/os/linux/vm/os_linux.cpp src/os/solaris/vm/os_solaris.cpp src/os/windows/vm/os_windows.cpp src/share/vm/runtime/os.hpp src/share/vm/runtime/thread.cpp test/runtime/6929067/T.java test/runtime/6929067/Test6929067.sh test/runtime/6929067/invoke.c description: 6929067: Stack guard pages should be removed when thread is detached Summary: Add code to unmap stack guard area when thread is detached. Reviewed-by: coleenp, kamg Based on my email archive for 6929067, the original reproducer was provided by Andrew Haley back on 2010.02.23 and that reproducer contained this line: options[0].optionString = "-Xss320k"; The original test program is pretty simple and doesn't do anything to grow the stack so it is not clear why the stack is limited to 320K. Force of habit for Andrew? Dunno. Dan > > Thanks, > > Jerry >> Hi Jerry, >> >> On 26/07/2016 22:55, Gerald Thornbrugh wrote: >>> Hi David, >>>> Hi Jerry, >>>> >>>> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>>>> Hi Everyone, >>>>> >>>>> I would like to have the following change reviewed: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>>>> >>>>> >>>>> >>>>> The stack size for this test needs to be increased to 384K for some >>>>> platforms. >>>> >>>> Is there a specific reason we set -Xss in the first place instead of >>>> just taking the platform defaults? If the platform stack settings >>>> change this test may need updating again. >>> >>> It was my understand (maybe incorrectly) that setting -Xss was an >>> attempt to limit the memory and time >>> resources the test takes. Using the smallest stack size allowable will >>> allocate less memory and reduce the >>> amount of time the test takes. Since I think Fred wrote the test he >>> would know better than I would. >>> >>> Fred, what is the reason behind specifying "-Xss" for this test? >> >> I'm not the author of this test, but I can try to contribute my >> two cents. >> >> I'm not seeing any particular reason to limit the stack size to >> 320KB other than reducing time and resources required for this >> test. >> >> Looking at the test history, Dmitry did the current version of the >> test, but the "-Xss320k" argument was already there before Dmitry >> re-wrote the test to fix 8042155. So it looks like a relic from >> old code for which the rational has been lost. >> >> Regarding the test, limiting the stack size looks a good idea to >> avoid wasting too much time and resources during testing. However, >> I'm seeing to reason to make the stack size "as small as possible". >> A 1MB stack size could already provide efficient improvement while >> avoiding platform dependent stack size constraint (and I'll be >> cursed for this by next generations of HotSpot developer as a >> 1MB limitation could become completely unjustified in the future). >> >> Fred >> >>> I have thought about the test harness setting an environment variable >>> and/or a java property to the correct >>> minimum values for "-Xss" depending upon the architecture the test is >>> running on. The tests could then use >>> the value to start each test. That way each test could be tailored for >>> the specific architecture. After looking into >>> this it looks the implementation would be significant and would be >>> outside the scope of this bug fix. >>> >>> Thanks, >>> >>> Jerry >>>> >>>> Thanks, >>>> David >>>> >>>>> My fix for JDK-8081770 >>>>> https://bugs.openjdk.java.net/browse/JDK-8081770 >>>>> moved the functionality >>>>> from the testme.sh script to exeinvoke.c so the dependency for a >>>>> local >>>>> compiler could be removed. >>>>> Because of this the stack size change needs to be applied to >>>>> exeinvoke.c >>>>> file instead of the testme.sh file. >>>>> >>>>> Please let me know if you have any questions or concerns. >>>>> >>>>> Thanks, >>>>> >>>>> Jerry >>> > From lois.foltan at oracle.com Wed Jul 27 17:41:37 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 27 Jul 2016 13:41:37 -0400 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass Message-ID: <5798F251.9000108@oracle.com> Hello, Please review the following fix: Webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ Bug: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass https://bugs.openjdk.java.net/browse/JDK-8160487 Summary: java.lang.reflect.Module is defined as a final class [1]. The VM was incorrectly checking for a subclass of java.lang.reflect.Module to validate a module. Testing: Ran full hotspot nightly testing tests, JCK vm & lang Thanks, Lois [1] http://download.java.net/java/jigsaw/docs/api/index.html From claes.redestad at oracle.com Wed Jul 27 17:54:46 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 Jul 2016 19:54:46 +0200 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: <5798F251.9000108@oracle.com> References: <5798F251.9000108@oracle.com> Message-ID: <5798F566.4000804@oracle.com> Hello, On 07/27/2016 07:41 PM, Lois Foltan wrote: > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ looks good to me! > > Bug: JVM Should Check If java.lang.reflect.Module is a Final Class Not > a Subclass > https://bugs.openjdk.java.net/browse/JDK-8160487 > > Summary: > java.lang.reflect.Module is defined as a final class [1]. The VM was > incorrectly checking for a subclass of java.lang.reflect.Module to > validate a module. Nit: The bug title strikes me as a bit weird, as it seems to imply it's about JVM checking that java.lang.reflect.Module is a final class, which is not what this fix is about. /Claes > > Testing: > Ran full hotspot nightly testing tests, JCK vm & lang > > Thanks, > Lois > > [1] http://download.java.net/java/jigsaw/docs/api/index.html From lois.foltan at oracle.com Wed Jul 27 18:01:31 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 27 Jul 2016 14:01:31 -0400 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: <5798F566.4000804@oracle.com> References: <5798F251.9000108@oracle.com> <5798F566.4000804@oracle.com> Message-ID: <5798F6FB.7050206@oracle.com> On 7/27/2016 1:54 PM, Claes Redestad wrote: > Hello, > > On 07/27/2016 07:41 PM, Lois Foltan wrote: >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ > > looks good to me! Thanks for the review! > >> >> Bug: JVM Should Check If java.lang.reflect.Module is a Final Class >> Not a Subclass >> https://bugs.openjdk.java.net/browse/JDK-8160487 >> >> Summary: >> java.lang.reflect.Module is defined as a final class [1]. The VM was >> incorrectly checking for a subclass of java.lang.reflect.Module to >> validate a module. > > Nit: The bug title strikes me as a bit weird, as it seems to imply > it's about JVM checking that java.lang.reflect.Module is a final > class, which is not what this fix is about. I agree, improved on the wording and changed to "JVM should validate a module by checking for an instance of java.lang.reflect.Module" Thanks, Lois > > /Claes > >> >> Testing: >> Ran full hotspot nightly testing tests, JCK vm & lang >> >> Thanks, >> Lois >> >> [1] http://download.java.net/java/jigsaw/docs/api/index.html > From coleen.phillimore at oracle.com Wed Jul 27 18:31:29 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Jul 2016 14:31:29 -0400 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: <5798F251.9000108@oracle.com> References: <5798F251.9000108@oracle.com> Message-ID: <2726a1b6-d6fc-a9e7-693b-478a9090a31a@oracle.com> This change looks good, but is there a test for it? thanks, Coleen On 7/27/16 1:41 PM, Lois Foltan wrote: > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ > > Bug: JVM Should Check If java.lang.reflect.Module is a Final Class Not > a Subclass > https://bugs.openjdk.java.net/browse/JDK-8160487 > > Summary: > java.lang.reflect.Module is defined as a final class [1]. The VM was > incorrectly checking for a subclass of java.lang.reflect.Module to > validate a module. > > Testing: > Ran full hotspot nightly testing tests, JCK vm & lang > > Thanks, > Lois > > [1] http://download.java.net/java/jigsaw/docs/api/index.html From Alan.Bateman at oracle.com Wed Jul 27 18:34:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Jul 2016 19:34:26 +0100 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: <5798F251.9000108@oracle.com> References: <5798F251.9000108@oracle.com> Message-ID: On 27/07/2016 18:41, Lois Foltan wrote: > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ > > Bug: JVM Should Check If java.lang.reflect.Module is a Final Class Not > a Subclass > https://bugs.openjdk.java.net/browse/JDK-8160487 > This looks okay to me. Module has always been final so I'm not sure how the subclass check crept in. -Alan From lois.foltan at oracle.com Wed Jul 27 18:37:55 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 27 Jul 2016 14:37:55 -0400 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: <2726a1b6-d6fc-a9e7-693b-478a9090a31a@oracle.com> References: <5798F251.9000108@oracle.com> <2726a1b6-d6fc-a9e7-693b-478a9090a31a@oracle.com> Message-ID: <5798FF83.8050200@oracle.com> On 7/27/2016 2:31 PM, Coleen Phillimore wrote: > > This change looks good, but is there a test for it? Thanks for the review. The test is at hotspot/test/runtime/modules/JVMDefineModule.java Lois > thanks, > Coleen > > On 7/27/16 1:41 PM, Lois Foltan wrote: >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ >> >> Bug: JVM Should Check If java.lang.reflect.Module is a Final Class >> Not a Subclass >> https://bugs.openjdk.java.net/browse/JDK-8160487 >> >> Summary: >> java.lang.reflect.Module is defined as a final class [1]. The VM was >> incorrectly checking for a subclass of java.lang.reflect.Module to >> validate a module. >> >> Testing: >> Ran full hotspot nightly testing tests, JCK vm & lang >> >> Thanks, >> Lois >> >> [1] http://download.java.net/java/jigsaw/docs/api/index.html > From lois.foltan at oracle.com Wed Jul 27 18:38:20 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 27 Jul 2016 14:38:20 -0400 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: References: <5798F251.9000108@oracle.com> Message-ID: <5798FF9C.4020106@oracle.com> On 7/27/2016 2:34 PM, Alan Bateman wrote: > On 27/07/2016 18:41, Lois Foltan wrote: > >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ >> >> Bug: JVM Should Check If java.lang.reflect.Module is a Final Class >> Not a Subclass >> https://bugs.openjdk.java.net/browse/JDK-8160487 >> > This looks okay to me. Module has always been final so I'm not sure > how the subclass check crept in. Thanks Alan for the review! Lois > > -Alan From coleen.phillimore at oracle.com Wed Jul 27 18:40:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Jul 2016 14:40:45 -0400 Subject: RFR (S) JDK-8160487: JVM Should Check If java.lang.reflect.Module is a Final Class Not a Subclass In-Reply-To: <5798FF83.8050200@oracle.com> References: <5798F251.9000108@oracle.com> <2726a1b6-d6fc-a9e7-693b-478a9090a31a@oracle.com> <5798FF83.8050200@oracle.com> Message-ID: <37bb530e-da31-c5dc-b6b7-4188ede292a6@oracle.com> On 7/27/16 2:37 PM, Lois Foltan wrote: > > On 7/27/2016 2:31 PM, Coleen Phillimore wrote: >> >> This change looks good, but is there a test for it? > > Thanks for the review. The test is at > hotspot/test/runtime/modules/JVMDefineModule.java Oh yeah, okay, I reviewed the test too.... just blurred with the rest. Coleen > Lois > >> thanks, >> Coleen >> >> On 7/27/16 1:41 PM, Lois Foltan wrote: >>> Hello, >>> >>> Please review the following fix: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8160487/webrev/ >>> >>> Bug: JVM Should Check If java.lang.reflect.Module is a Final Class >>> Not a Subclass >>> https://bugs.openjdk.java.net/browse/JDK-8160487 >>> >>> Summary: >>> java.lang.reflect.Module is defined as a final class [1]. The VM >>> was incorrectly checking for a subclass of java.lang.reflect.Module >>> to validate a module. >>> >>> Testing: >>> Ran full hotspot nightly testing tests, JCK vm & lang >>> >>> Thanks, >>> Lois >>> >>> [1] http://download.java.net/java/jigsaw/docs/api/index.html >> > From david.holmes at oracle.com Thu Jul 28 01:38:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Jul 2016 11:38:38 +1000 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <5798BBB3.6000805@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> <5798BBB3.6000805@oracle.com> Message-ID: On 27/07/2016 11:48 PM, Gerald Thornbrugh wrote: > Hi Fred, > > Thanks for the information. > > How does everyone feel about implementing Fred's suggestion of a stack > size of 1MB? > As Fred states this not a complete fix but it would provide relief from > this issue for the foreseeable future. I can live with it but I think it is unnecessary. Thanks, David > > Thanks, > > Jerry >> Hi Jerry, >> >> On 26/07/2016 22:55, Gerald Thornbrugh wrote: >>> Hi David, >>>> Hi Jerry, >>>> >>>> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>>>> Hi Everyone, >>>>> >>>>> I would like to have the following change reviewed: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>>>> >>>>> >>>>> The stack size for this test needs to be increased to 384K for some >>>>> platforms. >>>> >>>> Is there a specific reason we set -Xss in the first place instead of >>>> just taking the platform defaults? If the platform stack settings >>>> change this test may need updating again. >>> >>> It was my understand (maybe incorrectly) that setting -Xss was an >>> attempt to limit the memory and time >>> resources the test takes. Using the smallest stack size allowable will >>> allocate less memory and reduce the >>> amount of time the test takes. Since I think Fred wrote the test he >>> would know better than I would. >>> >>> Fred, what is the reason behind specifying "-Xss" for this test? >> >> I'm not the author of this test, but I can try to contribute my >> two cents. >> >> I'm not seeing any particular reason to limit the stack size to >> 320KB other than reducing time and resources required for this >> test. >> >> Looking at the test history, Dmitry did the current version of the >> test, but the "-Xss320k" argument was already there before Dmitry >> re-wrote the test to fix 8042155. So it looks like a relic from >> old code for which the rational has been lost. >> >> Regarding the test, limiting the stack size looks a good idea to >> avoid wasting too much time and resources during testing. However, >> I'm seeing to reason to make the stack size "as small as possible". >> A 1MB stack size could already provide efficient improvement while >> avoiding platform dependent stack size constraint (and I'll be >> cursed for this by next generations of HotSpot developer as a >> 1MB limitation could become completely unjustified in the future). >> >> Fred >> >>> I have thought about the test harness setting an environment variable >>> and/or a java property to the correct >>> minimum values for "-Xss" depending upon the architecture the test is >>> running on. The tests could then use >>> the value to start each test. That way each test could be tailored for >>> the specific architecture. After looking into >>> this it looks the implementation would be significant and would be >>> outside the scope of this bug fix. >>> >>> Thanks, >>> >>> Jerry >>>> >>>> Thanks, >>>> David >>>> >>>>> My fix for JDK-8081770 >>>>> https://bugs.openjdk.java.net/browse/JDK-8081770 >>>>> moved the functionality >>>>> from the testme.sh script to exeinvoke.c so the dependency for a local >>>>> compiler could be removed. >>>>> Because of this the stack size change needs to be applied to >>>>> exeinvoke.c >>>>> file instead of the testme.sh file. >>>>> >>>>> Please let me know if you have any questions or concerns. >>>>> >>>>> Thanks, >>>>> >>>>> Jerry >>> > From Alan.Burlison at oracle.com Thu Jul 28 15:58:46 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 28 Jul 2016 16:58:46 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> <5795D0E0.1080401@oracle.com> Message-ID: <579A2BB6.9040604@oracle.com> On 25/07/2016 21:20, Daniel D. Daugherty wrote: >>> I'm already setup to sponsor, but we're inside the QM window so >>> things are being disabled and shutdown as I type... :-( >> >> I'm guessing that's some sort of "gate closed" period? >> > > Oracle's reqular Quarterly Maintenance (QM) was this past weekend. > The systems (JPRT, testing, etc) needed for pushing changes into > the repos were down for maintenance. > > So the "gates" were probably open, but HotSpot forest protocol is > that all changes must go through systems that were down... Are we back in business now? -- Alan Burlison -- From gerald.thornbrugh at oracle.com Thu Jul 28 16:49:40 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Thu, 28 Jul 2016 10:49:40 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> <5798BBB3.6000805@oracle.com> Message-ID: <579A37A4.7090508@oracle.com> Hi Everyone, Here is the new webrev with the 1M change: http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.02/ Please let me know if you have questions or concerns. Thanks, jerry > On 27/07/2016 11:48 PM, Gerald Thornbrugh wrote: >> Hi Fred, >> >> Thanks for the information. >> >> How does everyone feel about implementing Fred's suggestion of a stack >> size of 1MB? >> As Fred states this not a complete fix but it would provide relief from >> this issue for the foreseeable future. > > I can live with it but I think it is unnecessary. > > Thanks, > David > >> >> Thanks, >> >> Jerry >>> Hi Jerry, >>> >>> On 26/07/2016 22:55, Gerald Thornbrugh wrote: >>>> Hi David, >>>>> Hi Jerry, >>>>> >>>>> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> I would like to have the following change reviewed: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>> The stack size for this test needs to be increased to 384K for some >>>>>> platforms. >>>>> >>>>> Is there a specific reason we set -Xss in the first place instead of >>>>> just taking the platform defaults? If the platform stack settings >>>>> change this test may need updating again. >>>> >>>> It was my understand (maybe incorrectly) that setting -Xss was an >>>> attempt to limit the memory and time >>>> resources the test takes. Using the smallest stack size allowable >>>> will >>>> allocate less memory and reduce the >>>> amount of time the test takes. Since I think Fred wrote the test he >>>> would know better than I would. >>>> >>>> Fred, what is the reason behind specifying "-Xss" for this test? >>> >>> I'm not the author of this test, but I can try to contribute my >>> two cents. >>> >>> I'm not seeing any particular reason to limit the stack size to >>> 320KB other than reducing time and resources required for this >>> test. >>> >>> Looking at the test history, Dmitry did the current version of the >>> test, but the "-Xss320k" argument was already there before Dmitry >>> re-wrote the test to fix 8042155. So it looks like a relic from >>> old code for which the rational has been lost. >>> >>> Regarding the test, limiting the stack size looks a good idea to >>> avoid wasting too much time and resources during testing. However, >>> I'm seeing to reason to make the stack size "as small as possible". >>> A 1MB stack size could already provide efficient improvement while >>> avoiding platform dependent stack size constraint (and I'll be >>> cursed for this by next generations of HotSpot developer as a >>> 1MB limitation could become completely unjustified in the future). >>> >>> Fred >>> >>>> I have thought about the test harness setting an environment variable >>>> and/or a java property to the correct >>>> minimum values for "-Xss" depending upon the architecture the test is >>>> running on. The tests could then use >>>> the value to start each test. That way each test could be tailored for >>>> the specific architecture. After looking into >>>> this it looks the implementation would be significant and would be >>>> outside the scope of this bug fix. >>>> >>>> Thanks, >>>> >>>> Jerry >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> My fix for JDK-8081770 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8081770 >>>>>> moved the functionality >>>>>> from the testme.sh script to exeinvoke.c so the dependency for a >>>>>> local >>>>>> compiler could be removed. >>>>>> Because of this the stack size change needs to be applied to >>>>>> exeinvoke.c >>>>>> file instead of the testme.sh file. >>>>>> >>>>>> Please let me know if you have any questions or concerns. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jerry >>>> >> From dean.long at oracle.com Thu Jul 28 18:53:56 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 28 Jul 2016 11:53:56 -0700 Subject: RFR(XS) 8029441: assert(!((nmethod*)_cb)->is_deopt_pc(_pc)) failed: invariant broken Message-ID: https://bugs.openjdk.java.net/browse/JDK-8029441 http://cr.openjdk.java.net/~dlong/8029441/webrev/ This assert happens if we are unlucky enough to be at the start of the deopt handler when another thread is calling JavaThread::pd_get_top_frame_for_profiling() on the first thread. In this case, the frame isn't going to be patched, so the assert is not helping. I removed the assert, but added a new assert to patch_pc() to make sure we don't try to patch an unpatchable frame. Tested with "hs-nightly-runtime", "hs-tier0-comp", and all the individual tests where this crash was happening. dl From daniel.daugherty at oracle.com Fri Jul 29 15:03:25 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Jul 2016 09:03:25 -0600 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <579A2BB6.9040604@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> <5795D0E0.1080401@oracle.com> <579A2BB6.9040604@oracle.com> Message-ID: <5375f998-c8db-9312-fc9b-9e9335785a90@oracle.com> On 7/28/16 9:58 AM, Alan Burlison wrote: > On 25/07/2016 21:20, Daniel D. Daugherty wrote: > >>>> I'm already setup to sponsor, but we're inside the QM window so >>>> things are being disabled and shutdown as I type... :-( >>> >>> I'm guessing that's some sort of "gate closed" period? >>> >> >> Oracle's reqular Quarterly Maintenance (QM) was this past weekend. >> The systems (JPRT, testing, etc) needed for pushing changes into >> the repos were down for maintenance. >> >> So the "gates" were probably open, but HotSpot forest protocol is >> that all changes must go through systems that were down... > > Are we back in business now? Sorry, I was out of the office for most of yesterday. I'll check to see where we are with this later today. Dan From shafi.s.ahmad at oracle.com Fri Jul 29 15:05:08 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Fri, 29 Jul 2016 08:05:08 -0700 (PDT) Subject: [8u] RFR JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) In-Reply-To: <1b64e628-c40a-dcd4-e41f-34b96d5a64b1@oracle.com> References: <4971842d-29db-4116-ac50-e506dcc14dc7@default> <1b64e628-c40a-dcd4-e41f-34b96d5a64b1@oracle.com> Message-ID: <87f1acfd-a331-4b91-8668-f17abd207319@default> Hi Coleen, Sorry for late reply. Thanks for the review. > -----Original Message----- > From: Coleen Phillimore > Sent: Monday, July 25, 2016 5:52 PM > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: [8u] RFR JDK-8161144: Fix for JDK-8147451 failed: Crash in > Method::checked_resolve_jmethod_id(_jmethodID*) > > > This looks good. Was this a backport or is it still broken in 9? This was not a backport. We are not able to reproduce in jdk9. Regards, Shafi > thanks, > Coleen > > On 7/25/16 7:53 AM, Shafi Ahmad wrote: > > Hi, > > > > Please review the small code change for bug: "JDK-8161144: Fix for JDK- > 8147451 failed: Crash in > Method::checked_resolve_jmethod_id(_jmethodID*)" on jdk8u-dev > > > > Summary: > > Method::deallocate_contents() should clear 'this' from list of Methods in > JNIMethodBlock, similarly to clear_all_methods() does it, when class is > unloaded. > > After this change I am seeing Method::is_method_id() is getting called with > NULL and I have done below change to avoid crash > > > > - assert(m != NULL, "should be called with non-null method"); > > + if (m == NULL) { > > + return false; > > + } > > > > Webrev: http://cr.openjdk.java.net/~shshahma/8161144/webrev/ > > Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8161144 > > > > Test: Run jprt > > > > Regards, > > Shafi > From daniel.daugherty at oracle.com Fri Jul 29 15:07:06 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Jul 2016 09:07:06 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <579A37A4.7090508@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> <5798BBB3.6000805@oracle.com> <579A37A4.7090508@oracle.com> Message-ID: <250fbb89-141b-4a11-2a1b-16f2515c082d@oracle.com> Thumbs up. Dan On 7/28/16 10:49 AM, Gerald Thornbrugh wrote: > Hi Everyone, > > Here is the new webrev with the 1M change: > > http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.02/ > > > Please let me know if you have questions or concerns. > > Thanks, > > jerry >> On 27/07/2016 11:48 PM, Gerald Thornbrugh wrote: >>> Hi Fred, >>> >>> Thanks for the information. >>> >>> How does everyone feel about implementing Fred's suggestion of a stack >>> size of 1MB? >>> As Fred states this not a complete fix but it would provide relief from >>> this issue for the foreseeable future. >> >> I can live with it but I think it is unnecessary. >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Jerry >>>> Hi Jerry, >>>> >>>> On 26/07/2016 22:55, Gerald Thornbrugh wrote: >>>>> Hi David, >>>>>> Hi Jerry, >>>>>> >>>>>> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>>>>>> Hi Everyone, >>>>>>> >>>>>>> I would like to have the following change reviewed: >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>>>>>> >>>>>>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The stack size for this test needs to be increased to 384K for some >>>>>>> platforms. >>>>>> >>>>>> Is there a specific reason we set -Xss in the first place instead of >>>>>> just taking the platform defaults? If the platform stack settings >>>>>> change this test may need updating again. >>>>> >>>>> It was my understand (maybe incorrectly) that setting -Xss was an >>>>> attempt to limit the memory and time >>>>> resources the test takes. Using the smallest stack size allowable >>>>> will >>>>> allocate less memory and reduce the >>>>> amount of time the test takes. Since I think Fred wrote the test he >>>>> would know better than I would. >>>>> >>>>> Fred, what is the reason behind specifying "-Xss" for this test? >>>> >>>> I'm not the author of this test, but I can try to contribute my >>>> two cents. >>>> >>>> I'm not seeing any particular reason to limit the stack size to >>>> 320KB other than reducing time and resources required for this >>>> test. >>>> >>>> Looking at the test history, Dmitry did the current version of the >>>> test, but the "-Xss320k" argument was already there before Dmitry >>>> re-wrote the test to fix 8042155. So it looks like a relic from >>>> old code for which the rational has been lost. >>>> >>>> Regarding the test, limiting the stack size looks a good idea to >>>> avoid wasting too much time and resources during testing. However, >>>> I'm seeing to reason to make the stack size "as small as possible". >>>> A 1MB stack size could already provide efficient improvement while >>>> avoiding platform dependent stack size constraint (and I'll be >>>> cursed for this by next generations of HotSpot developer as a >>>> 1MB limitation could become completely unjustified in the future). >>>> >>>> Fred >>>> >>>>> I have thought about the test harness setting an environment variable >>>>> and/or a java property to the correct >>>>> minimum values for "-Xss" depending upon the architecture the test is >>>>> running on. The tests could then use >>>>> the value to start each test. That way each test could be tailored >>>>> for >>>>> the specific architecture. After looking into >>>>> this it looks the implementation would be significant and would be >>>>> outside the scope of this bug fix. >>>>> >>>>> Thanks, >>>>> >>>>> Jerry >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> My fix for JDK-8081770 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081770 >>>>>>> moved the functionality >>>>>>> from the testme.sh script to exeinvoke.c so the dependency for a >>>>>>> local >>>>>>> compiler could be removed. >>>>>>> Because of this the stack size change needs to be applied to >>>>>>> exeinvoke.c >>>>>>> file instead of the testme.sh file. >>>>>>> >>>>>>> Please let me know if you have any questions or concerns. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jerry >>>>> >>> > From shafi.s.ahmad at oracle.com Fri Jul 29 15:10:16 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Fri, 29 Jul 2016 08:10:16 -0700 (PDT) Subject: [8u] RFR JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) In-Reply-To: <1b64e628-c40a-dcd4-e41f-34b96d5a64b1@oracle.com> References: <4971842d-29db-4116-ac50-e506dcc14dc7@default> <1b64e628-c40a-dcd4-e41f-34b96d5a64b1@oracle.com> Message-ID: <1c8198e3-0080-4f52-aa24-ef44751d7e71@default> Hi All, Could I have 2nd Reviewer's review for this change, please? Regards, Shafi > -----Original Message----- > From: Coleen Phillimore > Sent: Monday, July 25, 2016 5:52 PM > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: [8u] RFR JDK-8161144: Fix for JDK-8147451 failed: Crash in > Method::checked_resolve_jmethod_id(_jmethodID*) > > > This looks good. Was this a backport or is it still broken in 9? > thanks, > Coleen > > On 7/25/16 7:53 AM, Shafi Ahmad wrote: > > Hi, > > > > Please review the small code change for bug: "JDK-8161144: Fix for JDK- > 8147451 failed: Crash in > Method::checked_resolve_jmethod_id(_jmethodID*)" on jdk8u-dev > > > > Summary: > > Method::deallocate_contents() should clear 'this' from list of Methods in > JNIMethodBlock, similarly to clear_all_methods() does it, when class is > unloaded. > > After this change I am seeing Method::is_method_id() is getting called with > NULL and I have done below change to avoid crash > > > > - assert(m != NULL, "should be called with non-null method"); > > + if (m == NULL) { > > + return false; > > + } > > > > Webrev: http://cr.openjdk.java.net/~shshahma/8161144/webrev/ > > Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8161144 > > > > Test: Run jprt > > > > Regards, > > Shafi > From gerald.thornbrugh at oracle.com Fri Jul 29 15:15:49 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 29 Jul 2016 09:15:49 -0600 Subject: RFR 8161696 [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k In-Reply-To: <250fbb89-141b-4a11-2a1b-16f2515c082d@oracle.com> References: <57978A6B.6000906@oracle.com> <84715d69-1821-c277-9260-2ebc295c64f4@oracle.com> <579822B9.4040700@oracle.com> <59afd034-7487-003c-e90c-9a4e5b859937@oracle.com> <5798BBB3.6000805@oracle.com> <579A37A4.7090508@oracle.com> <250fbb89-141b-4a11-2a1b-16f2515c082d@oracle.com> Message-ID: <579B7325.8030908@oracle.com> Hi Dan, Thanks. Jerry > Thumbs up. > > Dan > > > On 7/28/16 10:49 AM, Gerald Thornbrugh wrote: >> Hi Everyone, >> >> Here is the new webrev with the 1M change: >> >> http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.02/ >> >> >> Please let me know if you have questions or concerns. >> >> Thanks, >> >> jerry >>> On 27/07/2016 11:48 PM, Gerald Thornbrugh wrote: >>>> Hi Fred, >>>> >>>> Thanks for the information. >>>> >>>> How does everyone feel about implementing Fred's suggestion of a stack >>>> size of 1MB? >>>> As Fred states this not a complete fix but it would provide relief >>>> from >>>> this issue for the foreseeable future. >>> >>> I can live with it but I think it is unnecessary. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Jerry >>>>> Hi Jerry, >>>>> >>>>> On 26/07/2016 22:55, Gerald Thornbrugh wrote: >>>>>> Hi David, >>>>>>> Hi Jerry, >>>>>>> >>>>>>> On 27/07/2016 2:06 AM, Gerald Thornbrugh wrote: >>>>>>>> Hi Everyone, >>>>>>>> >>>>>>>> I would like to have the following change reviewed: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161696 >>>>>>>> >>>>>>>> Webrev:http://cr.openjdk.java.net/~gthornbr/8161696/hotspot-webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The stack size for this test needs to be increased to 384K for >>>>>>>> some >>>>>>>> platforms. >>>>>>> >>>>>>> Is there a specific reason we set -Xss in the first place >>>>>>> instead of >>>>>>> just taking the platform defaults? If the platform stack settings >>>>>>> change this test may need updating again. >>>>>> >>>>>> It was my understand (maybe incorrectly) that setting -Xss was an >>>>>> attempt to limit the memory and time >>>>>> resources the test takes. Using the smallest stack size >>>>>> allowable will >>>>>> allocate less memory and reduce the >>>>>> amount of time the test takes. Since I think Fred wrote the test he >>>>>> would know better than I would. >>>>>> >>>>>> Fred, what is the reason behind specifying "-Xss" for this test? >>>>> >>>>> I'm not the author of this test, but I can try to contribute my >>>>> two cents. >>>>> >>>>> I'm not seeing any particular reason to limit the stack size to >>>>> 320KB other than reducing time and resources required for this >>>>> test. >>>>> >>>>> Looking at the test history, Dmitry did the current version of the >>>>> test, but the "-Xss320k" argument was already there before Dmitry >>>>> re-wrote the test to fix 8042155. So it looks like a relic from >>>>> old code for which the rational has been lost. >>>>> >>>>> Regarding the test, limiting the stack size looks a good idea to >>>>> avoid wasting too much time and resources during testing. However, >>>>> I'm seeing to reason to make the stack size "as small as possible". >>>>> A 1MB stack size could already provide efficient improvement while >>>>> avoiding platform dependent stack size constraint (and I'll be >>>>> cursed for this by next generations of HotSpot developer as a >>>>> 1MB limitation could become completely unjustified in the future). >>>>> >>>>> Fred >>>>> >>>>>> I have thought about the test harness setting an environment >>>>>> variable >>>>>> and/or a java property to the correct >>>>>> minimum values for "-Xss" depending upon the architecture the >>>>>> test is >>>>>> running on. The tests could then use >>>>>> the value to start each test. That way each test could be >>>>>> tailored for >>>>>> the specific architecture. After looking into >>>>>> this it looks the implementation would be significant and would be >>>>>> outside the scope of this bug fix. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jerry >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> My fix for JDK-8081770 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081770 >>>>>>>> moved the functionality >>>>>>>> from the testme.sh script to exeinvoke.c so the dependency for >>>>>>>> a local >>>>>>>> compiler could be removed. >>>>>>>> Because of this the stack size change needs to be applied to >>>>>>>> exeinvoke.c >>>>>>>> file instead of the testme.sh file. >>>>>>>> >>>>>>>> Please let me know if you have any questions or concerns. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jerry >>>>>> >>>> >> > From daniel.daugherty at oracle.com Fri Jul 29 15:38:26 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Jul 2016 09:38:26 -0600 Subject: RFR(XS) 8029441: assert(!((nmethod*)_cb)->is_deopt_pc(_pc)) failed: invariant broken In-Reply-To: References: Message-ID: On 7/28/16 12:53 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8029441 > > http://cr.openjdk.java.net/~dlong/8029441/webrev/ > > This assert happens if we are unlucky enough to be at the start of the > deopt handler when another thread is calling > JavaThread::pd_get_top_frame_for_profiling() on the first thread. In > this case, the frame isn't going to be patched, so the assert is not > helping. I removed the assert, but added a new assert to patch_pc() > to make sure we don't try to patch an unpatchable frame. Dusting off my stack sampling cobwebs... src/cpu/sparc/vm/frame_sparc.cpp So frame::init() has an assert about the current compiled PC not being a deopt PC. The sampling thread runs into this assert() in JavaThread::pd_get_top_frame() when it's trying to construct the top frame. The target thread happens to be just starting a deopt so that first frame's PC is a deopt PC. Ouch! Very nice catch of race that's probably been there a very long time. Update: Not very long in it's current form: 11069: assert(!((CompiledMethod*)_cb)->is_deopt_pc(_pc), "invariant broken"); $ hg log -r 11069 changeset: 11069:69d081845165 user: rbackman date: Tue Apr 26 10:28:51 2016 +0200 summary: 8151956: Support non-continuous CodeBlobs in HotSpot But very old in it's previous form: 0: assert(!((nmethod*)_cb)->is_deopt_pc(_pc), "invariant broken"); So back to SCCS history: 1.168.1.1 assert(!((nmethod*)_cb)->is_deopt_pc(_pc), "invariant broken"); $ sp -r1.168.1.1 src/cpu/sparc/vm/frame_sparc.cpp src/cpu/sparc/vm/SCCS/s.frame_sparc.cpp: D 1.168.1.1 06/12/07 10:06:37 sgoldman 298 297 00087/00035/00497 MRs: COMMENTS: 6463133 - patchless deopt. Automatically convert frames so that if they are deoptimized users can only see the original pc. Cache the codeblob that matches a frame's pc. So the earlier form of the assert dates back to Steve G's work on deopt. As for the new assert() in frame::patch_pc(), it looks fine to me but the proof is in the (long term) testing! Again, nice catch! Dan > > Tested with "hs-nightly-runtime", "hs-tier0-comp", and all the > individual tests where this crash was happening. > > dl > From Alan.Burlison at oracle.com Fri Jul 29 15:43:41 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 29 Jul 2016 16:43:41 +0100 Subject: RFR: JDK-8161601 Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed In-Reply-To: <5375f998-c8db-9312-fc9b-9e9335785a90@oracle.com> References: <5790BFA9.9010306@oracle.com> <0B8FA342-26EB-4FBD-A39D-70CCDC84609E@oracle.com> <5790C2C6.3090302@oracle.com> <33636edc-64c8-5b25-57c2-9c88f086847e@oracle.com> <5795D0E0.1080401@oracle.com> <579A2BB6.9040604@oracle.com> <5375f998-c8db-9312-fc9b-9e9335785a90@oracle.com> Message-ID: <579B79AD.7060701@oracle.com> On 29/07/2016 16:03, Daniel D. Daugherty wrote: >> Are we back in business now? > > Sorry, I was out of the office for most of yesterday. > > I'll check to see where we are with this later today. Ta :-) -- Alan Burlison -- From dean.long at oracle.com Fri Jul 29 17:13:40 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 29 Jul 2016 10:13:40 -0700 Subject: RFR(XS) 8029441: assert(!((nmethod*)_cb)->is_deopt_pc(_pc)) failed: invariant broken In-Reply-To: References: Message-ID: <9b82fd36-8fef-0bf4-2c31-6673a76ecce9@oracle.com> Thanks Dan! Does a compiler person want to look this over before I push? dl On 7/29/16 8:38 AM, Daniel D. Daugherty wrote: > On 7/28/16 12:53 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8029441 >> >> http://cr.openjdk.java.net/~dlong/8029441/webrev/ >> >> This assert happens if we are unlucky enough to be at the start of >> the deopt handler when another thread is calling >> JavaThread::pd_get_top_frame_for_profiling() on the first thread. In >> this case, the frame isn't going to be patched, so the assert is not >> helping. I removed the assert, but added a new assert to patch_pc() >> to make sure we don't try to patch an unpatchable frame. > > Dusting off my stack sampling cobwebs... > > src/cpu/sparc/vm/frame_sparc.cpp > So frame::init() has an assert about the current compiled PC > not being a deopt PC. The sampling thread runs into this assert() > in JavaThread::pd_get_top_frame() when it's trying to construct > the top frame. > > The target thread happens to be just starting a deopt so that > first frame's PC is a deopt PC. Ouch! Very nice catch of race > that's probably been there a very long time. > > Update: Not very long in it's current form: > > 11069: assert(!((CompiledMethod*)_cb)->is_deopt_pc(_pc), > "invariant broken"); > > $ hg log -r 11069 > changeset: 11069:69d081845165 > user: rbackman > date: Tue Apr 26 10:28:51 2016 +0200 > summary: 8151956: Support non-continuous CodeBlobs in HotSpot > > But very old in it's previous form: > > 0: assert(!((nmethod*)_cb)->is_deopt_pc(_pc), "invariant > broken"); > > So back to SCCS history: > > 1.168.1.1 assert(!((nmethod*)_cb)->is_deopt_pc(_pc), "invariant > broken"); > > $ sp -r1.168.1.1 src/cpu/sparc/vm/frame_sparc.cpp > src/cpu/sparc/vm/SCCS/s.frame_sparc.cpp: > > D 1.168.1.1 06/12/07 10:06:37 sgoldman 298 297 00087/00035/00497 > MRs: > COMMENTS: > 6463133 - patchless deopt. Automatically convert frames so that if > they > are deoptimized users can only see the original pc. Cache the > codeblob > that matches a frame's pc. > > So the earlier form of the assert dates back to Steve G's work on > deopt. > > > As for the new assert() in frame::patch_pc(), it looks fine to me > but the proof is in the (long term) testing! > > Again, nice catch! > > Dan > > >> >> Tested with "hs-nightly-runtime", "hs-tier0-comp", and all the >> individual tests where this crash was happening. >> >> dl >> >