Binary searching jdk repo to find a problematic commit?

[Dawid Weiss]

Thanks, I will test libjvm only, it does make sense. As for forks and
versions -- looking at the number of various forks here:

http://hg.openjdk.java.net/

I find it hard to figure out which repo is forked to which one and
what they are actually for. For example what's the difference between:

hsx/hotspot-main
and
hsx/hotspot-comp

Is the "main" a line which aggregates the compiler and the gc? Is
there any directed acyclic graph for newbies to understand the flow of
patches? :)

David: thanks for the tip. I know about bisect, it's also present in
git. I think for this I'd rather have some manual control (still
bisecting between known revisions, but manually) -- I'm still trying
to understand the way everything is tagged and versioned for releases
and the underlying flow of patches.

I'll report back if I find out something useful. That issue I look for
is still present with the tip of hsx/hotspot, by the way -- I check
pretty regularly.

Dawid


On Sat, Sep 7, 2013 at 8:22 PM, David Chase <david.r.chase at oracle.com> wrote:
> Dawid,
>
> For git versus mercurial, once you get your good and bad endpoints figured out for hotspot,
> you probably want to read "hg -v help bisect".  I've never used this feature myself, but it is
> clearly meant for this purpose.
>
> David
>
>
> On 2013-09-06, at 7:02 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Dawid,
>>
>> 7u3 uses Hotspot version hs22.1 (it is security release and has only bug fixes):
>>
>> Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
>> Java HotSpot(TM) Server VM (build 22.1-b02, mixed mode)
>>
>> It was based on hs22 in jdk7u2:
>>
>> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
>> Java HotSpot(TM) Server VM (build 22.0-b10, mixed mode)
>>
>> 7u4 start using Hotspot version hs23:
>>
>> Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b01)
>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode)
>>
>> If you think it is JVM problem you need to search VM changes (libjvm.so) which you can build separately and replace in one JDK (at exclude effects from jdk changes).
>>
>> Hotspot has separate repository where we do all development which is periodically forked for jdk releases:
>>
>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/
>>
>> Forked repository for hs23 is here:
>>
>> http://hg.openjdk.java.net/hsx/hsx23/hotspot/
>>
>> I think you should use it for your search.
>>
>> You need to do 'hg clone' first for revision you need:
>>
>> hg clone -r hs22-b06 http://hg.openjdk.java.net/hsx/hsx23/hotspot
>>
>> To build product VM:
>>
>> cd hotspot/make
>> gnumake product LP64=1 MAKE_VERBOSE=
>>
>> or to build fastdebug 32-bit:
>> gnumake fastdebug
>>
>> cp ../build/linux/linux_amd64_compiler2/fastdebug/libjvm.so <your_jdk_dir>/jre/lib/amd64/server/
>>
>> To pull next set of patches do:
>>
>> cd hotspot
>> hg pull -r hs23-b01
>>
>> Build and test again.
>>
>> Regards,
>> Vladimir
>>
>> On 9/6/13 2:29 PM, Dawid Weiss wrote:
>>>
>>> I'm more familiar with git than with mercurial, so this may be something
>>> obvious. I want to dissect commits made to hotspot between the official
>>> jdk7u3 and jdk7u4 and I've hit a couple of questions.
>>>
>>> 1) Interestingly the "top level" project doesn't have the tag my
>>> "official" jdk7u3 presents itself with:
>>>
>>> 1.7.0_03-b05
>>>
>>> the tags present in http://hg.openjdk.java.net/jdk7u/jdk7u are up to
>>> jdk7u3-b04. Which version was it built from? Is the tag missing?
>>>
>>> 2) When I look for build tags in between jdk7u3-b04:jdk7u4-b22 I see
>>> things like:
>>>
>>> $ hg log -r jdk7u3-b04:jdk7u4-b22 | grep "tag:"
>>> tag:         jdk7u3-b04
>>> tag:         jdk7u4-b13
>>> tag:         jdk7u4-b14
>>> tag:         jdk7u6-b01
>>> tag:         jdk7u6-b02
>>> ...
>>>
>>> This is slightly confusing to me but I guess it makes sense if parallel
>>> branches coexist in the same repo and are merged/ tagged at the same
>>> time. Anyway, would this series of tags really reflect something useful
>>> for a rough binary-searching scheme over incremental (semi-stable) builds?
>>>
>>> 3) I'm used to git's submodules which hold versioned references to
>>> sub-projects. I assume the forrest extension doesn't do it and every
>>> subproject is tagged at the time of the release, am I correct? What
>>> confused me was that the instructions to update sources
>>> in README-builds.html always pull subprojects to their tip. I assume to
>>> get the same set of sources I need to run something like:
>>>
>>> ./make/scripts/hgforest.sh pull <tag>
>>>
>>> (or an equivalent, depending on the JDK version)?
>>>
>>> Thanks for clarifying,
>>> Dawid
>>>
>>>
>