HotSpot 16 on OpenJDK6 build failure (was hg: jdk6/jdk6/hotspot: 3 new changesets)

Thu Feb 25 12:45:27 PST 2010

On 25 February 2010 00:36, Daniel D. Daugherty <Daniel.Daugherty at sun.com> wrote:
> Andrew John Hughes wrote:
>>
>> On 20 February 2010 16:17, Daniel D. Daugherty <Daniel.Daugherty at sun.com>
>> wrote:
>>
>>>
>>> Andrew John Hughes wrote:
>>>
>>>>
>>>> 2010/2/17 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>
>>>> Can we please have a solution for this?
>>>>
>>>
>>> Actually, I've been working on getting this fix into HSX-16
>>> even though I'm on a road trip (and on vacation).
>>>
>>>
>>
>> Ok.  I can't really tell this from my end when there is no response to
>> my e-mail.
>>
>
> Sorry, I forgot to set vacation mail when I left.
>
>
>>>> This changeset is NOT in the
>>>> hs16 master and is causing the OpenJDK6 build to fail once the hs16
>>>> master is imported, thus blocking our progress on preparing b19.
>>>>
>>>>
>>>
>>> I previously said that I pushed this fix to HSX-16.1 which is not
>>> the same as HSX-16. I never said that this fix is in the HSX-16
>>> master.
>>>
>>>
>>
>> Right, now that makes more sense.  I have no idea what HSX-16.1 is, so
>> I'd assumed that it was shorthand for b01 of hs16 rather than some
>> other repository we can't see.  The only repositories I'm aware of, in
>> addition to the OpenJDK6 and 7 ones, are the hsx16 base and master
>> ones.
>>
>
> When I fixed this bug in OpenJDK6/HSX-14, I should have also
> pushed the fix to HSX-16 (in addition to that HSX-16.1 thing :-)).
> I forgot that OpenJDK6 was moving to HSX-16 and not HSX-16.1.
> I tend not to pay attention to specific release trains. I just
> fix stuff where I think it needs to be fixed.
>
>
>>>> Using hs16 directly with OpenJDK6 works -- we have been doing this for
>>>> sometime.  As shown by the diff I posted, this conflicting changeset
>>>> is local to OpenJDK6.
>>>>
>>>>
>>>
>>> Yup. I thought I was doing the "right thing" by fixing this bug
>>> in OpenJDK6 also in addition to HSX-16.1 and HSX-17. Now I'm
>>> starting to wonder why I bother doing things for OpenJDK6 at all.
>>>
>>>
>>
>> I didn't say it was wrong to put it into OpenJDK6.  I merely wanted to
>> know how to fix the breakage that occurred when we updated OpenJDK6,
>> and was confused by what appeared to be a claim from you that the
>> patch was in the hs16 master when it clearly wasn't.
>>
>
> I think we're on the same page now. Erik will take care
> of getting the bits into the right public repos from here.
>
>
>>>> Is there a suitable default value for version so that we can
>>>> reintroduce the JvmtiEnv() constructor that was removed by your
>>>> changeset?
>>>>
>>>>
>>>
>>> When I ported the changeset to HSX-16, there was no need for a
>>> no-args constructor. I previously asked why you needed one and
>>> I don't see that answer in this e-mail thread. Perhaps I missed
>>> your reasons.
>>>
>>
>> I don't _need _ one.  I would have thought it was clear from the build
>> failure I posted in both the initial and last response.that another
>> part of the code is looking for the old no-args constructor i.e.
>>
>>
>>>>
>>>>
>>>> /home/andrew/projects/openjdk/upstream/jdk6/hotspot/src/share/vm/prims/jvmtiEnvThreadState.cpp
>>>>
>>>> /home/andrew/projects/openjdk/upstream/jdk6/hotspot/src/share/vm/prims/jvmtiEnvBase.cpp:126:
>>>> error: prototype for 'JvmtiEnvBase::JvmtiEnvBase()' does not match any
>>>> in class 'JvmtiEnvBase'
>>>>
>>>> /home/andrew/projects/openjdk/upstream/jdk6/hotspot/src/share/vm/prims/jvmtiEnvBase.hpp:44:
>>>> error: candidates are: JvmtiEnvBase::JvmtiEnvBase(const JvmtiEnvBase&)
>>>>
>>>> /home/andrew/projects/openjdk/upstream/jdk6/hotspot/src/share/vm/prims/jvmtiEnvBase.hpp:95:
>>>> error:                 JvmtiEnvBase::JvmtiEnvBase(jint)
>>>>
>
> I did see what you posted and I couldn't figure it out from the
> error messages. It didn't make any sense to me when I looked at
> the specific lines in the code (in my copy).
>
>
>> Maybe this call was added after the version of hs16 you ported to...
>> it's still unclear what that version is and whether we actually have
>> access to it.
>>
>
> I suspect that the problem had to do with how "you" merged the
> changesets into your repo. "you" in quotes because I think that
> automerge caused this problem. More below.
>
>
>>> I'll be pushing the ported changeset to HSX-16 baseline once I
>>> get back to Colorado. Right now I'm in New Mexico and expect to
>>> get home in 9-10 hours depending on the snow...
>>>
>>
>> Ok, I'll be surprised if that builds as that's effectively how it's
>> being applied to cause this failure -- the patch you made for OpenJDK6
>> is already there and the repository has been updated to the level of
>> hs16 master.
>>
>
> But it did build and now I'm troubled about why this merge didn't
> work for you. Here's the merge that I did:
>
> # the '-r ...' is just to create the merge_test repo at the
> # previous tip:
> % hg clone -r b9408ac1b596 \
>     http://hg.openjdk.java.net/hsx/hsx16/baseline merge_test
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 999 changesets with 9169 changes to 3765 files
> updating working directory
> 3568 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>
> # make sure I'm getting the two changesets I expect:
> % hg inc -r 98cd9901c161 http://hg.openjdk.java.net/jdk6/jdk6/hotspot
> comparing with http://hg.openjdk.java.net/jdk6/jdk6/hotspot
> searching for changes
> changeset:   999:9127aa69352e
> parent:      921:9601152ccfc1
> user:        dcubed
> date:        Mon Dec 14 09:51:09 2009 -0700
> summary:     6648438: 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 assert(phase
> == JVMTI_PHASE_LIVE,"sanity check")
>
> changeset:   1000:98cd9901c161
> tag:         tip
> user:        dcubed
> date:        Mon Dec 14 10:05:36 2009 -0700
> summary:     6849968: 3/2 JVMTI tests fails on jdk5.0 with hs14
>
>
> # get the changesets:
> % hg pull -u -r 98cd9901c161 http://hg.openjdk.java.net/jdk6/jdk6/hotspot
> pulling from http://hg.openjdk.java.net/jdk6/jdk6/hotspot
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 2 changesets with 7 changes to 6 files (+1 heads)
> abort: crosses branches (use 'hg merge' or 'hg update -C')
>
>
> # merge the conflicts:
> hg merge
> merging src/share/vm/prims/jvmtiEnv.cpp
> merging src/share/vm/prims/jvmtiEnvBase.cpp
> attempting automatic merge:
> merge: warning: conflicts during merge
> There are conflicts. attempting manual merge.
> calling filemerge for src/share/vm/prims/jvmtiEnvBase.cpp...
>
> # At this point, I had to manually merge two of the changes in
> # jvmtiEnvBase.cpp. The Mercurial auto merge couldn't handle it
> # and the automerge in the "filemerge" program couldn't handle
> # it either. Since one of the conflicted merges had to do with
> # the JvmtiEnvBase constructor, I'm guessing that might be what
> # happened in your situation. I don't know what merge tool you
> # use when Mercurial's automerge doesn't work, but that might
> # be what messed things up.
>
>
> # Make sure that all expected files are "modified" as part of
> # the hg merge:
> % hg status
> M src/share/vm/prims/jvmtiEnv.cpp
> M src/share/vm/prims/jvmtiEnvBase.cpp
> M src/share/vm/prims/jvmtiEnvBase.hpp
> M src/share/vm/prims/jvmtiExport.cpp
> M src/share/vm/prims/jvmtiExport.hpp
> M src/share/vm/prims/jvmtiHpp.xsl
>
>
> # Compare with the bits that I sent through JPRT for the
> # push last weekend:
>
> % diff {../../../../../bug_hunt/hsx16/exp/,}src/share/vm/prims/jvmtiEnv.cpp
>
> % diff
> {../../../../../bug_hunt/hsx16/exp/,}src/share/vm/prims/jvmtiEnvBase.cpp
>
> % diff
> {../../../../../bug_hunt/hsx16/exp/,}src/share/vm/prims/jvmtiEnvBase.hpp
>
> % diff
> {../../../../../bug_hunt/hsx16/exp/,}src/share/vm/prims/jvmtiExport.cpp
>
> % diff
> {../../../../../bug_hunt/hsx16/exp/,}src/share/vm/prims/jvmtiExport.hpp
>
> % diff {../../../../../bug_hunt/hsx16/exp/,}src/share/vm/prims/jvmtiHpp.xsl
>
>
> # At this point, all that is left is the "hg commit".
>
> Please let me know if you concur that "automerge" is what caused
> this problem.
>
> Dan
>
>

I can confirm there was no merging of
hotspot/src/share/vm/prims/jvmtiEnv.cpp.  The problem is not from my
merge, but because the source of HotSpot 14 to which your original
OpenJDK6 patch was applied is different to the sources of HotSpot 14.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8