Merging the MacOS X Port into HotSpot Express 23 (7098194)
Paul Hohensee
paul.hohensee at oracle.com
Wed Oct 12 14:19:59 PDT 2011
Do we really need to keep in sync with the old macosx-port project?
Afaic, we're just using that code as a starting point for this project.
I second Tom's suggestion to move the USDT1/2 distinction into
a header file. Doing so would make this changeset a whole lot smaller.
Paul
On 10/12/11 4:12 PM, Daniel D. Daugherty wrote:
> On 10/12/11 12:27 PM, Tom Rodriguez wrote:
>> I'm working on a review and this is what I have so far. I'll send
>> more later.
>>
>> On the issue of the dtrace changes, couldn't we minimize later
>> disruption by moving the USDT1/USDT2 distinction into a header file?
>> For instance, instead of doing this:
>>
>> +#ifndef USDT2
>>
>> HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0);
>>
>> +#else /* USDT2 */
>> + HOTSPOT_THREAD_SLEEP_END(
>> + 0);
>> +#endif /* USDT2 */
>>
>> Couldn't it just have
>>
>> HOTSPOT_THREAD_SLEEP_END(0);
>>
>> with this ifdef in a header somewhere?
>>
>> #ifndef USDT2
>> #define HOTSPOT_THREAD_SLEEP_END(arg) \
>> HS_DTRACE_PROBE1(hotspot, thread__sleep__end, (arg))
>> #endif /* USDT2 */
>>
>> It minimizes the ugly until we resolve the real issue. I guess the
>> PROBE_DECL stuff will have to be somewhere else too. Anyway, I'm
>> fine with pushing it as is but I wanted to at least mention this.
>
> I'll include this in the new bug as a way to phase in the
> changes from USDT1 -> USDT2. I don't want to make that
> change now since it will make it more difficult to keep
> in sync with the MacOS X port project.
>
>
>> connode.cpp:
>>
>> why is ia64_double_zero being defined? There are no uses of it
>> anywhere.
>
> I saw your newer posting. I'll file a bug for this also.
>
>
>> os_bsd.cpp:
>>
>> there's a fix for a minor memory leak in there which should also be
>> fixed in os_linux.cpp:
>>
>> if (v != NULL) {
>> char *t = ld_library_path;
>> /* That's +1 for the colon and +1 for the trailing '\0' */
>> ld_library_path = (char *) malloc(strlen(v) + 1 +
>> strlen(t) + 1);
>> sprintf(ld_library_path, "%s:%s", v, t);
>> + free(t);
>> }
>
> Yup. It's on my notes list.
>
>
>> bsd_x86_32.s:
>>
>> This apple fix isn't needed since p2align is already aligning to 16
>> bytes. In the mac assembler .align is the same as .p2align which is
>> why it's reducing it to 4.
>>
>> - .p2align 4,,15
>> +#ifdef __APPLE__
>> + .align 4
>> +#else
>> + .align 16
>> +#endif
>>
>> The second alignment change isn't needed because of this:
>>
>> 82 ELF_TYPE(SafeFetch32, at function)
>> 83 .p2align 4,,15
>
> I noticed that I screwed that up just after I sent out the
> review request so it was discussed a bit earlier in this
> thread.
>
> Thanks for the thorough review.
>
> Dan
>
>
>> tom
>>
>> On Oct 11, 2011, at 10:34 AM, 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
>>>
>
More information about the hotspot-dev
mailing list