Binary searching jdk repo to find a problematic commit?

[Dawid Weiss]

Tested with -XX:-OptimizePtrCompare, here are the results:

> changeset:   2874:8c57262447d3
ant test -Dtests.failfast=true -Dtests.seed=CF -Dtests.jvms=1 \
    -Dtests.dynamicAssignmentRatio=0 -Dargs="-server -XX:+UseG1GC \
    -XX:-TieredCompilation -Xbatch -XX:CICompilerCount=1 \
    -XX:-OptimizePtrCompare"

=> PASSED

advanced to one-before-the-problem:

> changeset:   2882:db2e64ca2d5a
ant test -Dtests.failfast=true -Dtests.seed=CF -Dtests.jvms=1 \
    -Dtests.dynamicAssignmentRatio=0 -Dargs="-server -XX:+UseG1GC \
    -XX:-TieredCompilation -Xbatch -XX:CICompilerCount=1 \
    -XX:-OptimizePtrCompare"

=> PASSED

but the next one again causes the bug.

> changeset:   2883:cc81b9c09bbb
ant test -Dtests.failfast=true -Dtests.seed=CF -Dtests.jvms=1 \
    -Dtests.dynamicAssignmentRatio=0 -Dargs="-server -XX:+UseG1GC \
    -XX:-TieredCompilation -Xbatch -XX:CICompilerCount=1 \
    -XX:-OptimizePtrCompare"

=> ASSERTION HIT

I'll send you access details to that vbox on prv.

Dawid


On Wed, Sep 11, 2013 at 7:52 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> Now that I know which change triggers the problem I can do some more
> digging. For the record -- JDK8 also exhibits the same problem, but it
> only surfaces in 32-bit JVM (and the same thing applies to JDK7 --
> only 32 bit mode is affected). Perhaps the patch in question only
> helps another issue to become visible by changing the opto graph, I
> don't know.
>
> I'll do some more testing around the code fragments you indicated and
> will let you know.
>
> Dawid
>
>
> On Wed, Sep 11, 2013 at 3:46 AM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> On 9/10/13 3:26 AM, Dawid Weiss wrote:
>>>
>>> No need to be sorry, David -- a hint too many is better than no hint at
>>> all :)
>>>
>>> Anyway. I did the backtracking -- it required some time because I had
>>> to set up an environment from two years back (old ubuntu in a virtual
>>> machine). I did some binary searching and probing and narrowed the
>>> problem to this commit:
>>>
>>> changeset:   2883:cc81b9c09bbb
>>> user:        kvn
>>> date:        Mon Nov 28 15:46:31 2011 -0800
>>> summary:     7112478: after 7105605 JRuby
>>> bench_define_method_methods.rb fails with NPE
>>>
>>> (Since 'kvn' seems to be Vladimir I believe I was bothering the right
>>> person all the time ;)
>>
>>
>> Yes, you caught me :)
>>
>> What worries me is that you tested with -XX:-OptimizePtrCompare and still
>> got the problem.
>> Can you test 2874(7105605) changeset with  -XX:-OptimizePtrCompare to see if
>> your problem was introduced by it but was hidden by NPE problem?
>>
>> And there was 6890673 changes in between. Which could also introduce the
>> problem. Test it is also with -XX:-OptimizePtrCompare if testing of 7105605
>> shows nothing.
>>
>> There was several followup fixes after 7112478 changes but all of them are
>> present in 7u40 (for example, 7129284 and 7146442). So I don't see
>> outstanding changes in escape.cpp in jdk8 which helped to fix the problem.
>> But it could be fix in an other file. You said before that you don't have
>> problem with jdk8. If you have spare testing cycles can you find which
>> changes fixed it?
>>
>> Next step will be bisecting 7112478 changes.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> After this commit the problem with assertion-tripping in Lucene starts
>>> to consistently show up (you already know it's not the assertion
>>> itself but the underlying issue of missed update causing it). The
>>> commits before 2883 -- everything after 2874 7(105605) all end up in a
>>>
>>> null pointer, probably as mentioned in the above commit summary. I
>>> have a strong feeling the fix introduced in 2883 fixed the NPE but
>>> introduced a regression somewhere else because 2873 works just fine.
>>>
>>> I looked at the patch but it goes too deep for me to understand given
>>> the limited time I have for this pet project. If there's anything else
>>> I can help you with, Vladimir, ask. I can provide an image of ubuntu
>>> 9.04 (virtualbox) which reproduces the issue every time I run the test
>>> suite (couldn't extract a smaller, isolated test case though).
>>>
>>> Dawid
>>>
>>> On Mon, Sep 9, 2013 at 7:08 PM, David Chase <david.r.chase at oracle.com>
>>> wrote:
>>>>
>>>>
>>>> On 2013-09-07, at 3:44 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>>>>
>>>>> David: thanks for the tip. I know about bisect, it's also present in
>>>>> git. ...
>>>>
>>>>
>>>> Oh, sorry, I just assumed you were as ignorant of hg as I am of git.
>>>> I know that one of the gripes about our why-have-just-one-tree repository
>>>> design is that it gets in the way of exactly what you want to do.
>>>>
>>>> David
>>>>
>>