Binary searching jdk repo to find a problematic commit?

[Dawid Weiss]

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