Binary searching jdk repo to find a problematic commit?

[David Chase]

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
>> 
>>