Merging the MacOS X Port into HotSpot Express 23 (7098194)
Paul Hohensee
paul.hohensee at oracle.com
Wed Oct 12 15:07:57 PDT 2011
On 10/12/11 6:00 PM, Daniel D. Daugherty wrote:
> On 10/12/11 3:19 PM, Paul Hohensee wrote:
>> Do we really need to keep in sync with the old macosx-port project?
>
> Yes. That's one of the ways that I'm keeping this port project sane.
> As far as I know, the bsd-port/hotspot and macosx-port/hotspot repos
> have not yet been retired. If I have to resync with either of those
> repos again before they are retired, then I would like that to go
> smoothly.
Ok. Maybe someone can tell me when they'll be retired, or if they're
relevant to a jdk7 port. I see what I can find out.
>
>
>> Afaic, we're just using that code as a starting point for this project.
>
> 'Afaic' or 'Afaik'? (care or know?)
"concerned". :)
>
> Yes, we're using that code as a starting point for this project, but
> I don't yet have testing up and running on MacOS X so I don't want to
> make non-trivial MacOS X changes blind.
>
>
>> 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.
>
> Not going to happen in this changeset. I will file another bug to do
> more work on USDT1/2 stuff, but I don't yet have a way to test making
> a change like that on MacOS X.
Reluctantly, Ok.
Paul
>
> Dan
>
>
>
>>
>> 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