Merging the MacOS X Port into HotSpot Express 23 (7098194)

[Keith McGuigan]

FWIW, I believe the build platform for jdk7 is Solaris 10, which does  
support USDT2, as far as I know.  So if we can convert to use USDT2  
all the time and drop the USDT1 code, that would be good.

--
- Keith

On Oct 11, 2011, at 4:25 PM, roger hoover wrote:

> I did the USDT2 implementation with some mechanical tools and a lot  
> of by-hand followup.  My intension was to leave the structure of the  
> USDT1 macro calls in place.  Most of the USDT2 changes are a  
> smallish delta on the USDT1 macro calls.  If we were to have macro- 
> in-a-macro capabilities, we could implement this small difference  
> with another macro.
>
> Fortunately for sanity's sake, macros-in-macros don't work well in  
> the C preprocessor, and I had to duplicate the entire macro call.   
> If Oracle moves the Solaris implementation from USDT1 to USDT2, then  
> by all means the USDT2 code should be cleaned up.  On the other  
> hand, if the USDT1 implementation is to live on, any formatting  
> changes should enhance the ability to make consistent modifications  
> to both USDT1 and USDT2.
>
> roger
>
> On Oct 11, 2011, at    12:58 PM, Vladimir Kozlov wrote:
>
>> Dan,
>>
>> Why new Dtrace implementation for MacOS X use 2 lines where it is  
>> not needed (a lot of places)? For example:
>>
>> +#else /* USDT2 */
>> +  HOTSPOT_GC_END(
>> +);
>> +#endif /* USDT2 */
>>
>> Is this what you called "does not follow HotSpot style guidelines  
>> very consistently"?
>>
>> Thanks,
>> Vladimir
>>
>> Daniel D. Daugherty wrote:
>>> Greetings,
>>> Tom R shepherded the the BSD Port into HotSpot Express 23 using:
>>>   7089790 integrate bsd-port changes
>>> and I'm following up on that work using the following bug:
>>>   7098194 integrate macosx-port changes
>>> The synopsis is a bit off. In reality, the 7098194changeset will
>>> include additional changes from the BSD Port in addition the deltas
>>> made by the MacOS X Port. The bsd-port/hotspot tip changeset for
>>> this resync is:
>>>   changeset:   2729:f1a18ada5853
>>>   tag:         tip
>>>   user:        Greg Lewis <glewis at eyesbeyond.com>
>>>   date:        Wed Sep 21 22:29:10 2011 -0700
>>>   summary:     . Finish removing hsearch_r.
>>> The macosx-port/hotspot changeset for this merge is:
>>>   changeset:   2756:69de8d34a370
>>>   tag:         tip
>>>   user:        swingler at apple.com
>>>   date:        Thu Sep 29 18:10:16 2011 -0700
>>>   summary:     Adding JAVA_LIBRARY_PATH for bundled app launching
>>>                (avoids stomping DYLD_LIBRARY_PATH)
>>> The focus of 7098194 is to get the MacOS X port into HSX-23 without
>>> regressing the non-MacOS X platforms. In other words, we're trying
>>> to get HSX-23 caught up with the BSD Port and MacOS X Port projects.
>>> Shaking out the MacOS X Port itself will be done with other  
>>> changesets
>>> on an as needed basis.
>>> Just to be clear, the push target for this changeset is the  
>>> RT_Baseline
>>> sub-repo of HotSpot Express (currently HSX-23):
>>>   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot
>>> Like what Tom did for 7089790, I'm posting multiple webrevs so folks
>>> can review these changes in different ways. My primary focus here is
>>> the common or shared code so I'm less worried about the BSD or  
>>> MacOS X
>>> specific changes. Obviously, if you see something I messed up in  
>>> those
>>> files, I'd like to know.
>>> Here's the webrev for all the changes in one shot:
>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-all/
>>>   The order of the files in the above webrev is the same as for
>>>   for the subset webrevs below.
>>> Here's the webrevs for the changes in subsets:
>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-bsd-resync/ 
>>>      The above webrev has the changes to the bsd-port/hotspot repo  
>>> made
>>>   after Tom R's work on 7089790 (the 2011.08.02 wiki snapshot).
>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-other-code/ 
>>>      The above webrev has the non-Dtrace and non-infrastructure  
>>> changes
>>>   made for the MacOS X port. There's a couple of files that also  
>>> contain
>>>   Dtrace related changes, but I decided it was better to include  
>>> those
>>>   files in this subset.
>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-dtrace-code/ 
>>>      The above webrev has almost all of the changes to enable  
>>> Dtrace on
>>>   MacOS X (a couple of files are in the macosx-other-code subset).
>>>   On MacOS X, a newer version of Dtrace is implemented than on  
>>> Solaris
>>>   which is why the code is #ifdef'ed. I had to change the original
>>>   #ifdef'ing because the original implementation had put some non- 
>>> Dtrace
>>>   code into #ifdef USDT1 ... #endif blocks so the code didn't  
>>> build on
>>>   non-Solaris platforms. In order to be more clean with  
>>> #ifdef'ing, I
>>>   redid all MacOS X Dtrace #ifdef'ing in the following forms:
>>>       #ifndef USDT2
>>> <older Dtrace implementation is in this block>
>>> <some non-Dtrace code (macros) that call the older Dtrace>
>>> <implementation are also in this block>
>>>       #else /* USDT2 */
>>> <new Dtrace implementation for MacOS X in this block>
>>>       #endif /* USDT2 */
>>>       #ifndef USDT2
>>> <older Dtrace implementation is in this block>
>>> <no #else because the newer Dtrace doesn't need/have the equivalent>
>>>       #endif /* ! USDT2 */
>>>   Yes, I realize that the MacOS X Dtrace implementation does not  
>>> follow
>>>   HotSpot style guidelines very consistently, but I decided not to  
>>> fix
>>>   that so I could diff against the macosx-port/hotspot more  
>>> reliably.
>>>   I have to consult with Keith McGuigan about how to migrate the  
>>> Solaris
>>>   Dtrace implementation to the newer version. However, that work  
>>> will be
>>>   done independently of this bug (7098194).
>>> http://cr.openjdk.java.net/~dcubed/mac_os_x_port/7098194-webrev/0-macosx-infra/ 
>>>      The above webrev has all the infrastructure (e.g., Makefile)  
>>> related
>>>   changes. Many/most folks aren't interested in Makefile stuff so  
>>> I've
>>>   put these changes in their own subset. Of course, I need Kelly  
>>> O'Hair
>>>   to bless these changes...
>>> Builds done so far:
>>> - Solaris X86 builds of {Client, Server} VM * {product, fastdebug,  
>>> jvmg}
>>> - WinXP builds of {Client, Server} VM * {product, fastdebug, debug}
>>> - MacOS 10.6.8/Xcode 3.2.6 build of the macosx-port forest with  
>>> new HSX repo
>>> - MacOS 10.7/Xcode 4.1.1 build of the macosx-port forest with new  
>>> HSX repo
>>> Testing done so far:
>>> - Serviceability stack (25 subsuites):
>>> VM/NSK: jvmti, jvmti_unit, jdwp, jdi, sa-jdi, heapdump, hprof, jdb,
>>>         logging, mm
>>> SDK/JDK: jdi, jdi_closed, jli, logging, mm_csjmx, mm_csm, mm_jlm,
>>>          mm_jlm_closed, mm_jmx, mm_jmx_closed, mm_sm, mm_sm_closed,
>>>          misc_attach, misc_jvmstat, misc_tools
>>> - Tested configs (8 configs)
>>> {Solaris X86, WinXP} * {Client, Server} VM * {-Xmixed, -Xcomp}
>>> - MacOS X builds have only had minimal 'java -version' type testing,
>>> i.e., did the build "work"?
>>> No regressions have been seen in the Solaris X86 testing and WinXP
>>> testing should be finished later today.
>>> Things still to do (in no particular order):
>>> - gather the list of contributors for the changeset comment
>>> - JPRT test jobs when the JPRT-hotspotwest queue settles down
>>> - dtrace testing on Solaris X86
>>> - code review
>>> - start bring up of more formal dev testing on MacOS X
>>> Thanks, in advance, for any review comments.
>>> Dan
>