From tom.rodriguez at oracle.com  Fri Apr  1 01:57:40 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Fri, 01 Apr 2011 08:57:40 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 6385687:
	UseFastEmptyMethods/UseFastAccessorMethods considered harmful
Message-ID: <20110401085745.94F62476BC@hg.openjdk.java.net>

Changeset: c2323e2ea62b
Author:    never
Date:      2011-03-31 21:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c2323e2ea62b

6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful
Reviewed-by: kvn, jrose, phh

! src/share/vm/prims/jvmtiManageCapabilities.cpp
! src/share/vm/runtime/globals.hpp


From gbenson at redhat.com  Fri Apr  1 02:28:46 2011
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 1 Apr 2011 10:28:46 +0100
Subject: Review Request: Zero and Shark fixes
In-Reply-To: <20110331182441.GD6143@rivendell.middle-earth.co.uk>
References: <AANLkTin7L6ueJbeEwjiRcQK4S3V0fPCnYGLHaCY6sDK1@mail.gmail.com>
	<5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com>
	<AANLkTikbzfy2b=m4W6OWyeg9jGdjyRg2zswUo8SAkrYP@mail.gmail.com>
	<F3FEF032-E18A-4596-992C-38F01FB05DBA@oracle.com>
	<AANLkTinvva_nLNsxQrnHmwd8txbp9GE+KjPaBtjmMQdY@mail.gmail.com>
	<20110331092125.GA3884@redhat.com>
	<AANLkTimatH=LqMdUj-UpX=A_6s7_z=idM9iOaM7_prKi@mail.gmail.com>
	<20110331172645.GE3884@redhat.com>
	<AANLkTi=TLZwsawrwxkMkbLydUjqrVE1FW_etHx_C74F9@mail.gmail.com>
	<20110331182441.GD6143@rivendell.middle-earth.co.uk>
Message-ID: <20110401092846.GA4281@redhat.com>

Dr Andrew John Hughes wrote:
> On 19:20 Thu 31 Mar     , Dr Andrew John Hughes wrote:
> > Errr... what ARM interpreter rewrite?

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/004957.html

> Sorry for the top-post; stupid broken Gmail client... Didn't realise
> I had this mail in my RH inbox too.

http://www.gnu.org/philosophy/javascript-trap.html

From gbenson at redhat.com  Fri Apr  1 02:39:31 2011
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 1 Apr 2011 10:39:31 +0100
Subject: UseFastEmptyMethods/UseFastAccessorMethods considered harmful
In-Reply-To: <20110401085745.94F62476BC@hg.openjdk.java.net>
References: <20110401085745.94F62476BC@hg.openjdk.java.net>
Message-ID: <20110401093931.GB4281@redhat.com>

Hi all,

I just spotted that UseFastEmptyMethods and UseFastAccessorMethods
are now off by default.  Zero and Shark both benefit hugely from
having these on, especially for accessors.  Would it be possible
to make it platform-specific somehow?

Thanks,
Gary

-- 
http://gbenson.net/

From gnu_andrew at member.fsf.org  Fri Apr  1 02:48:59 2011
From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes)
Date: Fri, 1 Apr 2011 10:48:59 +0100
Subject: Review Request: Zero and Shark fixes
In-Reply-To: <20110401092846.GA4281@redhat.com>
References: <AANLkTin7L6ueJbeEwjiRcQK4S3V0fPCnYGLHaCY6sDK1@mail.gmail.com>
	<5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com>
	<AANLkTikbzfy2b=m4W6OWyeg9jGdjyRg2zswUo8SAkrYP@mail.gmail.com>
	<F3FEF032-E18A-4596-992C-38F01FB05DBA@oracle.com>
	<AANLkTinvva_nLNsxQrnHmwd8txbp9GE+KjPaBtjmMQdY@mail.gmail.com>
	<20110331092125.GA3884@redhat.com>
	<AANLkTimatH=LqMdUj-UpX=A_6s7_z=idM9iOaM7_prKi@mail.gmail.com>
	<20110331172645.GE3884@redhat.com>
	<AANLkTi=TLZwsawrwxkMkbLydUjqrVE1FW_etHx_C74F9@mail.gmail.com>
	<20110331182441.GD6143@rivendell.middle-earth.co.uk>
	<20110401092846.GA4281@redhat.com>
Message-ID: <BANLkTi=0CuGKtoVcLyUVJ_PJMG2RixH5Ag@mail.gmail.com>

On 01/04/2011, Gary Benson <gbenson at redhat.com> wrote:
> Dr Andrew John Hughes wrote:
>> On 19:20 Thu 31 Mar     , Dr Andrew John Hughes wrote:
>> > Errr... what ARM interpreter rewrite?
>
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/004957.html
>

Ah, I wondered if it was that.  Did you add this to IcedTea yet?

>> Sorry for the top-post; stupid broken Gmail client... Didn't realise
>> I had this mail in my RH inbox too.
>
> http://www.gnu.org/philosophy/javascript-trap.html
>

It's turning the Javascript off that's made the top-posting worse.
I'll have to move this hotspot list to my RH inbox as well as the
others.
-- 
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

From gbenson at redhat.com  Fri Apr  1 07:33:42 2011
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 1 Apr 2011 15:33:42 +0100
Subject: Review Request: Zero JSR 292 support
Message-ID: <20110401143341.GG4281@redhat.com>

Hi all,

This webrev adds support for JSR 292 to Zero:

  http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/

Note that is is designed to apply after the fix for 7032458,
which is currently under review and can be found here:

  http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-2/

I don't have a bug id for this.

Cheers,
Gary

-- 
http://gbenson.net/

From roland.westrelin at oracle.com  Fri Apr  1 08:49:15 2011
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 01 Apr 2011 17:49:15 +0200
Subject: review request (M): 7033154 Improve C1 arraycopy performance 
Message-ID: <op.vs9nkdm6rz1tqb@grosvic>

http://cr.openjdk.java.net/~roland/7033154/webrev.00/

From tom.rodriguez at oracle.com  Fri Apr  1 10:32:21 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 10:32:21 -0700
Subject: UseFastEmptyMethods/UseFastAccessorMethods considered harmful
In-Reply-To: <20110401093931.GB4281@redhat.com>
References: <20110401085745.94F62476BC@hg.openjdk.java.net>
	<20110401093931.GB4281@redhat.com>
Message-ID: <20C6AF91-AED6-40D1-8821-9FABC9F19C92@oracle.com>


On Apr 1, 2011, at 2:39 AM, Gary Benson wrote:

> Hi all,
> 
> I just spotted that UseFastEmptyMethods and UseFastAccessorMethods
> are now off by default.  Zero and Shark both benefit hugely from
> having these on, especially for accessors.  Would it be possible
> to make it platform-specific somehow?

I had considered turning them on in interpreter only mode but that wouldn't help Shark.  Maybe I should restore the default and just turn them off in Arguments::set_mode_flags for COMPILER1 || COMPILER2.  Otherwise we'd need to made them product_pd which is kind of a pain.  I'll send out an updated review.

tom

> 
> Thanks,
> Gary
> 
> -- 
> http://gbenson.net/


From tom.rodriguez at oracle.com  Fri Apr  1 14:55:37 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 14:55:37 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store elimination
Message-ID: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>

I could push this to hotspot-gc so it gets more CMS testing .

http://cr.openjdk.java.net/~never/7032963

7032963: StoreCM shouldn't participate in store elimination
Reviewed-by:

StoreCM shouldn't participate in redundant store elimination since
that could violate the requirement that a StoreCM must be strictly
after a field update.  This results in a large number of redundant
StoreCMs being emitted for blocks of fields updates, so I added an
optimization to fold them up safely.  Previously the extra dependence
was converted into a precedence edge just before register allocation
but I moved this logic into final_graph_reshape.  I then added logic
to search through chains of StoreCMs to eliminate earlier redundant
ones and transfer their precedence edges to the one that is kept.
This ensures that they are scheduled properly.  This actually
eliminates duplicates that were previously missed so the code quality
is slightly better.  Tested by inspecting code generation with script
to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
-XX:+UseG1GC.


From y.s.ramakrishna at oracle.com  Fri Apr  1 15:13:40 2011
From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna)
Date: Fri, 01 Apr 2011 15:13:40 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
Message-ID: <4D964E14.7040405@oracle.com>

On 4/1/2011 2:55 PM, Tom Rodriguez wrote:
> I could push this to hotspot-gc so it gets more CMS testing .

That would be a very good idea (CMS as well as G1 testing, actually)!

I can't review your changes, lacking sufficient bkgrd or
familiarity with the code, but ...

> This actually
>> eliminates duplicates that were previously missed so the code quality
>> is slightly better.

wow! What more could one ask for --you fixed a correctness
bug _and_ got us a bit more performance. Hmm, by chance does
the fix also come with a free bottle of beer for all of us? ;-)

-- ramki

>
> http://cr.openjdk.java.net/~never/7032963
>
> 7032963: StoreCM shouldn't participate in store elimination
> Reviewed-by:
>
> StoreCM shouldn't participate in redundant store elimination since
> that could violate the requirement that a StoreCM must be strictly
> after a field update.  This results in a large number of redundant
> StoreCMs being emitted for blocks of fields updates, so I added an
> optimization to fold them up safely.  Previously the extra dependence
> was converted into a precedence edge just before register allocation
> but I moved this logic into final_graph_reshape.  I then added logic
> to search through chains of StoreCMs to eliminate earlier redundant
> ones and transfer their precedence edges to the one that is kept.
> This ensures that they are scheduled properly.  This actually
> eliminates duplicates that were previously missed so the code quality
> is slightly better.  Tested by inspecting code generation with script
> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
> -XX:+UseG1GC.
>


From vladimir.kozlov at oracle.com  Fri Apr  1 15:47:04 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 01 Apr 2011 15:47:04 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
Message-ID: <4D9655E8.9050003@oracle.com>

You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals 
before the loop. Also you need to kill the node explicitly otherwise it still be 
connected to its inputs:

+         // Eliminate the previous StoreCM
+         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
+         assert(mem->outcnt() == 0, "should be dead");
+         mem->disconnect_inputs(NULL);

Vladimir

Tom Rodriguez wrote:
> I could push this to hotspot-gc so it gets more CMS testing .
> 
> http://cr.openjdk.java.net/~never/7032963
> 
> 7032963: StoreCM shouldn't participate in store elimination
> Reviewed-by:
> 
> StoreCM shouldn't participate in redundant store elimination since
> that could violate the requirement that a StoreCM must be strictly
> after a field update.  This results in a large number of redundant
> StoreCMs being emitted for blocks of fields updates, so I added an
> optimization to fold them up safely.  Previously the extra dependence
> was converted into a precedence edge just before register allocation
> but I moved this logic into final_graph_reshape.  I then added logic
> to search through chains of StoreCMs to eliminate earlier redundant
> ones and transfer their precedence edges to the one that is kept.
> This ensures that they are scheduled properly.  This actually
> eliminates duplicates that were previously missed so the code quality
> is slightly better.  Tested by inspecting code generation with script
> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
> -XX:+UseG1GC.
> 

From tom.rodriguez at oracle.com  Fri Apr  1 16:26:54 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 16:26:54 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <4D9655E8.9050003@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
Message-ID: <12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>


On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:

> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals before the loop. Also you need to kill the node explicitly otherwise it still be connected to its inputs:
> 
> +         // Eliminate the previous StoreCM
> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
> +         assert(mem->outcnt() == 0, "should be dead");
> +         mem->disconnect_inputs(NULL);

I'll have to rework the mem traversal a little.  Actually I think there might have been a bug with the old code since it always updated prev.  I believe this is correct:

        // Eliminate the previous StoreCM                                                                                                             
        prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
        assert(mem->outcnt() == 0, "should be dead");
        mem->disconnect_inputs(NULL);
      } else {                                                                                                                                       
        prev = mem;                                                                                                                                   
      }
      mem = prev->in(MemNode::Memory);
    }

I think I'll put together a little test case to make sure this is working correctly.

tom

> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> I could push this to hotspot-gc so it gets more CMS testing .
>> http://cr.openjdk.java.net/~never/7032963
>> 7032963: StoreCM shouldn't participate in store elimination
>> Reviewed-by:
>> StoreCM shouldn't participate in redundant store elimination since
>> that could violate the requirement that a StoreCM must be strictly
>> after a field update.  This results in a large number of redundant
>> StoreCMs being emitted for blocks of fields updates, so I added an
>> optimization to fold them up safely.  Previously the extra dependence
>> was converted into a precedence edge just before register allocation
>> but I moved this logic into final_graph_reshape.  I then added logic
>> to search through chains of StoreCMs to eliminate earlier redundant
>> ones and transfer their precedence edges to the one that is kept.
>> This ensures that they are scheduled properly.  This actually
>> eliminates duplicates that were previously missed so the code quality
>> is slightly better.  Tested by inspecting code generation with script
>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>> -XX:+UseG1GC.


From tom.rodriguez at oracle.com  Fri Apr  1 16:29:27 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 16:29:27 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <4D964E14.7040405@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D964E14.7040405@oracle.com>
Message-ID: <6988EBE2-402E-4BA6-BF1A-A7DA19547846@oracle.com>


On Apr 1, 2011, at 3:13 PM, Y. Srinivas Ramakrishna wrote:

> On 4/1/2011 2:55 PM, Tom Rodriguez wrote:
>> I could push this to hotspot-gc so it gets more CMS testing .
> 
> That would be a very good idea (CMS as well as G1 testing, actually)!
> 
> I can't review your changes, lacking sufficient bkgrd or
> familiarity with the code, but ...
> 
>> This actually
>>> eliminates duplicates that were previously missed so the code quality
>>> is slightly better.
> 
> wow! What more could one ask for --you fixed a correctness
> bug _and_ got us a bit more performance.

I have some other ideas about improving the code for barriers that occurred to me while looking at the conditional card marks code.  It would mainly help with the G1 code and might require a little extra work but it's simpler than the more extensive changes we've talked about before.

> Hmm, by chance does
> the fix also come with a free bottle of beer for all of us? ;-)

If you stop by my office I'd be happy to give you a beer. ;)

tom

> 
> -- ramki
> 
>> 
>> http://cr.openjdk.java.net/~never/7032963
>> 
>> 7032963: StoreCM shouldn't participate in store elimination
>> Reviewed-by:
>> 
>> StoreCM shouldn't participate in redundant store elimination since
>> that could violate the requirement that a StoreCM must be strictly
>> after a field update.  This results in a large number of redundant
>> StoreCMs being emitted for blocks of fields updates, so I added an
>> optimization to fold them up safely.  Previously the extra dependence
>> was converted into a precedence edge just before register allocation
>> but I moved this logic into final_graph_reshape.  I then added logic
>> to search through chains of StoreCMs to eliminate earlier redundant
>> ones and transfer their precedence edges to the one that is kept.
>> This ensures that they are scheduled properly.  This actually
>> eliminates duplicates that were previously missed so the code quality
>> is slightly better.  Tested by inspecting code generation with script
>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>> -XX:+UseG1GC.
>> 
> 


From vladimir.kozlov at oracle.com  Fri Apr  1 16:37:14 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 01 Apr 2011 16:37:14 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
	<12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
Message-ID: <4D9661AA.6070400@oracle.com>

An other problem if n is on a branch and you could eliminate dominated StoreCM 
which above the split point resulting in not having StoreCM on opposite branch.

Vladimir

Tom Rodriguez wrote:
> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
> 
>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals before the loop. Also you need to kill the node explicitly otherwise it still be connected to its inputs:
>>
>> +         // Eliminate the previous StoreCM
>> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>> +         assert(mem->outcnt() == 0, "should be dead");
>> +         mem->disconnect_inputs(NULL);
> 
> I'll have to rework the mem traversal a little.  Actually I think there might have been a bug with the old code since it always updated prev.  I believe this is correct:
> 
>         // Eliminate the previous StoreCM                                                                                                             
>         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>         assert(mem->outcnt() == 0, "should be dead");
>         mem->disconnect_inputs(NULL);
>       } else {                                                                                                                                       
>         prev = mem;                                                                                                                                   
>       }
>       mem = prev->in(MemNode::Memory);
>     }
> 
> I think I'll put together a little test case to make sure this is working correctly.
> 
> tom
> 
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> I could push this to hotspot-gc so it gets more CMS testing .
>>> http://cr.openjdk.java.net/~never/7032963
>>> 7032963: StoreCM shouldn't participate in store elimination
>>> Reviewed-by:
>>> StoreCM shouldn't participate in redundant store elimination since
>>> that could violate the requirement that a StoreCM must be strictly
>>> after a field update.  This results in a large number of redundant
>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>> optimization to fold them up safely.  Previously the extra dependence
>>> was converted into a precedence edge just before register allocation
>>> but I moved this logic into final_graph_reshape.  I then added logic
>>> to search through chains of StoreCMs to eliminate earlier redundant
>>> ones and transfer their precedence edges to the one that is kept.
>>> This ensures that they are scheduled properly.  This actually
>>> eliminates duplicates that were previously missed so the code quality
>>> is slightly better.  Tested by inspecting code generation with script
>>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>>> -XX:+UseG1GC.
> 

From tom.rodriguez at oracle.com  Fri Apr  1 16:58:36 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 16:58:36 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <4D9661AA.6070400@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
	<12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
	<4D9661AA.6070400@oracle.com>
Message-ID: <656262C7-8969-45AA-A8D5-FED8D07BFD39@oracle.com>


On Apr 1, 2011, at 4:37 PM, Vladimir Kozlov wrote:

> An other problem if n is on a branch and you could eliminate dominated StoreCM which above the split point resulting in not having StoreCM on opposite branch.

You mean:

a.f = x
b.f = y;
if (test)
  return
a.b = c;

The StoreCM for a.f has a single user but it's used by the StoreCM of b.f which has multiple users.  So I think the search needs to stop when it encounters multiple users of a StoreCM since that represents a split of control flow.  Thanks for catching that.

Sounds like a job for partial redundancy elimination.

tom

> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
>>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals before the loop. Also you need to kill the node explicitly otherwise it still be connected to its inputs:
>>> 
>>> +         // Eliminate the previous StoreCM
>>> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>> +         assert(mem->outcnt() == 0, "should be dead");
>>> +         mem->disconnect_inputs(NULL);
>> I'll have to rework the mem traversal a little.  Actually I think there might have been a bug with the old code since it always updated prev.  I believe this is correct:
>>        // Eliminate the previous StoreCM                                                                                                                     prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>        assert(mem->outcnt() == 0, "should be dead");
>>        mem->disconnect_inputs(NULL);
>>      } else {                                                                                                                                               prev = mem;                                                                                                                                         }
>>      mem = prev->in(MemNode::Memory);
>>    }
>> I think I'll put together a little test case to make sure this is working correctly.
>> tom
>>> Vladimir
>>> 
>>> Tom Rodriguez wrote:
>>>> I could push this to hotspot-gc so it gets more CMS testing .
>>>> http://cr.openjdk.java.net/~never/7032963
>>>> 7032963: StoreCM shouldn't participate in store elimination
>>>> Reviewed-by:
>>>> StoreCM shouldn't participate in redundant store elimination since
>>>> that could violate the requirement that a StoreCM must be strictly
>>>> after a field update.  This results in a large number of redundant
>>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>>> optimization to fold them up safely.  Previously the extra dependence
>>>> was converted into a precedence edge just before register allocation
>>>> but I moved this logic into final_graph_reshape.  I then added logic
>>>> to search through chains of StoreCMs to eliminate earlier redundant
>>>> ones and transfer their precedence edges to the one that is kept.
>>>> This ensures that they are scheduled properly.  This actually
>>>> eliminates duplicates that were previously missed so the code quality
>>>> is slightly better.  Tested by inspecting code generation with script
>>>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>>>> -XX:+UseG1GC.


From vladimir.kozlov at oracle.com  Fri Apr  1 17:08:08 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 01 Apr 2011 17:08:08 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <656262C7-8969-45AA-A8D5-FED8D07BFD39@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
	<12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
	<4D9661AA.6070400@oracle.com>
	<656262C7-8969-45AA-A8D5-FED8D07BFD39@oracle.com>
Message-ID: <4D9668E8.3020407@oracle.com>

Actually I thought about slightly different case:

a.f = x
if (test) {
   a.b = y;
}

But StoreCM for a.f should have several users (StoreCM for a.b and mergemem) so 
your condition (stop serch if multiple users) stays true.

Vladimir

Tom Rodriguez wrote:
> On Apr 1, 2011, at 4:37 PM, Vladimir Kozlov wrote:
> 
>> An other problem if n is on a branch and you could eliminate dominated StoreCM which above the split point resulting in not having StoreCM on opposite branch.
> 
> You mean:
> 
> a.f = x
> b.f = y;
> if (test)
>   return
> a.b = c;
> 
> The StoreCM for a.f has a single user but it's used by the StoreCM of b.f which has multiple users.  So I think the search needs to stop when it encounters multiple users of a StoreCM since that represents a split of control flow.  Thanks for catching that.
> 
> Sounds like a job for partial redundancy elimination.
> 
> tom
> 
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
>>>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals before the loop. Also you need to kill the node explicitly otherwise it still be connected to its inputs:
>>>>
>>>> +         // Eliminate the previous StoreCM
>>>> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>> +         assert(mem->outcnt() == 0, "should be dead");
>>>> +         mem->disconnect_inputs(NULL);
>>> I'll have to rework the mem traversal a little.  Actually I think there might have been a bug with the old code since it always updated prev.  I believe this is correct:
>>>        // Eliminate the previous StoreCM                                                                                                                     prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>        assert(mem->outcnt() == 0, "should be dead");
>>>        mem->disconnect_inputs(NULL);
>>>      } else {                                                                                                                                               prev = mem;                                                                                                                                         }
>>>      mem = prev->in(MemNode::Memory);
>>>    }
>>> I think I'll put together a little test case to make sure this is working correctly.
>>> tom
>>>> Vladimir
>>>>
>>>> Tom Rodriguez wrote:
>>>>> I could push this to hotspot-gc so it gets more CMS testing .
>>>>> http://cr.openjdk.java.net/~never/7032963
>>>>> 7032963: StoreCM shouldn't participate in store elimination
>>>>> Reviewed-by:
>>>>> StoreCM shouldn't participate in redundant store elimination since
>>>>> that could violate the requirement that a StoreCM must be strictly
>>>>> after a field update.  This results in a large number of redundant
>>>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>>>> optimization to fold them up safely.  Previously the extra dependence
>>>>> was converted into a precedence edge just before register allocation
>>>>> but I moved this logic into final_graph_reshape.  I then added logic
>>>>> to search through chains of StoreCMs to eliminate earlier redundant
>>>>> ones and transfer their precedence edges to the one that is kept.
>>>>> This ensures that they are scheduled properly.  This actually
>>>>> eliminates duplicates that were previously missed so the code quality
>>>>> is slightly better.  Tested by inspecting code generation with script
>>>>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>>>>> -XX:+UseG1GC.
> 

From vladimir.kozlov at oracle.com  Fri Apr  1 17:15:31 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 01 Apr 2011 17:15:31 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <4D9668E8.3020407@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
	<12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
	<4D9661AA.6070400@oracle.com>
	<656262C7-8969-45AA-A8D5-FED8D07BFD39@oracle.com>
	<4D9668E8.3020407@oracle.com>
Message-ID: <4D966AA3.804@oracle.com>

And, it seems, your current code covers this case already. So my false 
assumption helped you to find the real problem ;)

Thanks,
Vladimir

Vladimir Kozlov wrote:
> Actually I thought about slightly different case:
> 
> a.f = x
> if (test) {
>   a.b = y;
> }
> 
> But StoreCM for a.f should have several users (StoreCM for a.b and 
> mergemem) so your condition (stop serch if multiple users) stays true.
> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> On Apr 1, 2011, at 4:37 PM, Vladimir Kozlov wrote:
>>
>>> An other problem if n is on a branch and you could eliminate 
>>> dominated StoreCM which above the split point resulting in not having 
>>> StoreCM on opposite branch.
>>
>> You mean:
>>
>> a.f = x
>> b.f = y;
>> if (test)
>>   return
>> a.b = c;
>>
>> The StoreCM for a.f has a single user but it's used by the StoreCM of 
>> b.f which has multiple users.  So I think the search needs to stop 
>> when it encounters multiple users of a StoreCM since that represents a 
>> split of control flow.  Thanks for catching that.
>>
>> Sounds like a job for partial redundancy elimination.
>>
>> tom
>>
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
>>>>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) 
>>>>> into locals before the loop. Also you need to kill the node 
>>>>> explicitly otherwise it still be connected to its inputs:
>>>>>
>>>>> +         // Eliminate the previous StoreCM
>>>>> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>> +         assert(mem->outcnt() == 0, "should be dead");
>>>>> +         mem->disconnect_inputs(NULL);
>>>> I'll have to rework the mem traversal a little.  Actually I think 
>>>> there might have been a bug with the old code since it always 
>>>> updated prev.  I believe this is correct:
>>>>        // Eliminate the previous 
>>>> StoreCM                                                                                                                     
>>>> prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>        assert(mem->outcnt() == 0, "should be dead");
>>>>        mem->disconnect_inputs(NULL);
>>>>      } else 
>>>> {                                                                                                                                               
>>>> prev = 
>>>> mem;                                                                                                                                         
>>>> }
>>>>      mem = prev->in(MemNode::Memory);
>>>>    }
>>>> I think I'll put together a little test case to make sure this is 
>>>> working correctly.
>>>> tom
>>>>> Vladimir
>>>>>
>>>>> Tom Rodriguez wrote:
>>>>>> I could push this to hotspot-gc so it gets more CMS testing .
>>>>>> http://cr.openjdk.java.net/~never/7032963
>>>>>> 7032963: StoreCM shouldn't participate in store elimination
>>>>>> Reviewed-by:
>>>>>> StoreCM shouldn't participate in redundant store elimination since
>>>>>> that could violate the requirement that a StoreCM must be strictly
>>>>>> after a field update.  This results in a large number of redundant
>>>>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>>>>> optimization to fold them up safely.  Previously the extra dependence
>>>>>> was converted into a precedence edge just before register allocation
>>>>>> but I moved this logic into final_graph_reshape.  I then added logic
>>>>>> to search through chains of StoreCMs to eliminate earlier redundant
>>>>>> ones and transfer their precedence edges to the one that is kept.
>>>>>> This ensures that they are scheduled properly.  This actually
>>>>>> eliminates duplicates that were previously missed so the code quality
>>>>>> is slightly better.  Tested by inspecting code generation with script
>>>>>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>>>>>> -XX:+UseG1GC.
>>

From tom.rodriguez at oracle.com  Fri Apr  1 17:36:21 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 17:36:21 -0700
Subject: review (S) for 6909440: C2 fails with assertion
	(_always_cold->is_cold(), "must always be cold")
Message-ID: <D5250908-B21B-42D7-8891-24ACA71882BE@oracle.com>

http://cr.openjdk.java.net/~never/6909440

6909440: C2 fails with assertion (_always_cold->is_cold(),"must always be cold")
Reviewed-by:

The always_cold and always_hot objects are initialized lazily which
relies on the initialization occurring before it's published but the
windows x64 code publishes it first which creates a tiny race where
another thread can see the uninitialized value.  I probably could have
put in a volatile but I decided to just initialize them in the normal
way using a static constructor.  Tested with failing test from report.


From vladimir.kozlov at oracle.com  Fri Apr  1 17:40:27 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 01 Apr 2011 17:40:27 -0700
Subject: review (S) for 6909440: C2 fails with assertion
	(_always_cold->is_cold(), "must always be cold")
In-Reply-To: <D5250908-B21B-42D7-8891-24ACA71882BE@oracle.com>
References: <D5250908-B21B-42D7-8891-24ACA71882BE@oracle.com>
Message-ID: <4D96707B.3010206@oracle.com>

Good.

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6909440
> 
> 6909440: C2 fails with assertion (_always_cold->is_cold(),"must always be cold")
> Reviewed-by:
> 
> The always_cold and always_hot objects are initialized lazily which
> relies on the initialization occurring before it's published but the
> windows x64 code publishes it first which creates a tiny race where
> another thread can see the uninitialized value.  I probably could have
> put in a volatile but I decided to just initialize them in the normal
> way using a static constructor.  Tested with failing test from report.
> 

From tom.rodriguez at oracle.com  Fri Apr  1 18:05:15 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 1 Apr 2011 18:05:15 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <4D966AA3.804@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
	<12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
	<4D9661AA.6070400@oracle.com>
	<656262C7-8969-45AA-A8D5-FED8D07BFD39@oracle.com>
	<4D9668E8.3020407@oracle.com> <4D966AA3.804@oracle.com>
Message-ID: <375A0C90-548D-49FB-B6D6-CAB8800C382D@oracle.com>

It turns out that the code I wrote is safe from this bug because the CastP2X has control so the card mark addresses don't appear to be the same since the CastP2X's are different.  Picking a higher control is the basis of the other idea I had for improving the barrier code since it improves the sharing of card mark computations.  If I enable that logic then the bug in my code shows up.  I've fixed it by checking for outcnt() == 1 in the main loop control.

tom

On Apr 1, 2011, at 5:15 PM, Vladimir Kozlov wrote:

> And, it seems, your current code covers this case already. So my false assumption helped you to find the real problem ;)
> 
> Thanks,
> Vladimir
> 
> Vladimir Kozlov wrote:
>> Actually I thought about slightly different case:
>> a.f = x
>> if (test) {
>>  a.b = y;
>> }
>> But StoreCM for a.f should have several users (StoreCM for a.b and mergemem) so your condition (stop serch if multiple users) stays true.
>> Vladimir
>> Tom Rodriguez wrote:
>>> On Apr 1, 2011, at 4:37 PM, Vladimir Kozlov wrote:
>>> 
>>>> An other problem if n is on a branch and you could eliminate dominated StoreCM which above the split point resulting in not having StoreCM on opposite branch.
>>> 
>>> You mean:
>>> 
>>> a.f = x
>>> b.f = y;
>>> if (test)
>>>  return
>>> a.b = c;
>>> 
>>> The StoreCM for a.f has a single user but it's used by the StoreCM of b.f which has multiple users.  So I think the search needs to stop when it encounters multiple users of a StoreCM since that represents a split of control flow.  Thanks for catching that.
>>> 
>>> Sounds like a job for partial redundancy elimination.
>>> 
>>> tom
>>> 
>>>> Vladimir
>>>> 
>>>> Tom Rodriguez wrote:
>>>>> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
>>>>>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals before the loop. Also you need to kill the node explicitly otherwise it still be connected to its inputs:
>>>>>> 
>>>>>> +         // Eliminate the previous StoreCM
>>>>>> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>>> +         assert(mem->outcnt() == 0, "should be dead");
>>>>>> +         mem->disconnect_inputs(NULL);
>>>>> I'll have to rework the mem traversal a little.  Actually I think there might have been a bug with the old code since it always updated prev.  I believe this is correct:
>>>>>       // Eliminate the previous StoreCM                                                                                                                     prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>>       assert(mem->outcnt() == 0, "should be dead");
>>>>>       mem->disconnect_inputs(NULL);
>>>>>     } else {                                                                                                                                               prev = mem;                                                                                                                                         }
>>>>>     mem = prev->in(MemNode::Memory);
>>>>>   }
>>>>> I think I'll put together a little test case to make sure this is working correctly.
>>>>> tom
>>>>>> Vladimir
>>>>>> 
>>>>>> Tom Rodriguez wrote:
>>>>>>> I could push this to hotspot-gc so it gets more CMS testing .
>>>>>>> http://cr.openjdk.java.net/~never/7032963
>>>>>>> 7032963: StoreCM shouldn't participate in store elimination
>>>>>>> Reviewed-by:
>>>>>>> StoreCM shouldn't participate in redundant store elimination since
>>>>>>> that could violate the requirement that a StoreCM must be strictly
>>>>>>> after a field update.  This results in a large number of redundant
>>>>>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>>>>>> optimization to fold them up safely.  Previously the extra dependence
>>>>>>> was converted into a precedence edge just before register allocation
>>>>>>> but I moved this logic into final_graph_reshape.  I then added logic
>>>>>>> to search through chains of StoreCMs to eliminate earlier redundant
>>>>>>> ones and transfer their precedence edges to the one that is kept.
>>>>>>> This ensures that they are scheduled properly.  This actually
>>>>>>> eliminates duplicates that were previously missed so the code quality
>>>>>>> is slightly better.  Tested by inspecting code generation with script
>>>>>>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>>>>>>> -XX:+UseG1GC.
>>> 


From vladimir.kozlov at oracle.com  Fri Apr  1 18:07:58 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 01 Apr 2011 18:07:58 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <375A0C90-548D-49FB-B6D6-CAB8800C382D@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D9655E8.9050003@oracle.com>
	<12783E68-E28E-44BB-85D1-911369EEBA41@oracle.com>
	<4D9661AA.6070400@oracle.com>
	<656262C7-8969-45AA-A8D5-FED8D07BFD39@oracle.com>
	<4D9668E8.3020407@oracle.com> <4D966AA3.804@oracle.com>
	<375A0C90-548D-49FB-B6D6-CAB8800C382D@oracle.com>
Message-ID: <4D9676EE.5000007@oracle.com>

Yes, this looks right.

Thanks,
Vladimir

Tom Rodriguez wrote:
> It turns out that the code I wrote is safe from this bug because the CastP2X has control so the card mark addresses don't appear to be the same since the CastP2X's are different.  Picking a higher control is the basis of the other idea I had for improving the barrier code since it improves the sharing of card mark computations.  If I enable that logic then the bug in my code shows up.  I've fixed it by checking for outcnt() == 1 in the main loop control.
> 
> tom
> 
> On Apr 1, 2011, at 5:15 PM, Vladimir Kozlov wrote:
> 
>> And, it seems, your current code covers this case already. So my false assumption helped you to find the real problem ;)
>>
>> Thanks,
>> Vladimir
>>
>> Vladimir Kozlov wrote:
>>> Actually I thought about slightly different case:
>>> a.f = x
>>> if (test) {
>>>  a.b = y;
>>> }
>>> But StoreCM for a.f should have several users (StoreCM for a.b and mergemem) so your condition (stop serch if multiple users) stays true.
>>> Vladimir
>>> Tom Rodriguez wrote:
>>>> On Apr 1, 2011, at 4:37 PM, Vladimir Kozlov wrote:
>>>>
>>>>> An other problem if n is on a branch and you could eliminate dominated StoreCM which above the split point resulting in not having StoreCM on opposite branch.
>>>> You mean:
>>>>
>>>> a.f = x
>>>> b.f = y;
>>>> if (test)
>>>>  return
>>>> a.b = c;
>>>>
>>>> The StoreCM for a.f has a single user but it's used by the StoreCM of b.f which has multiple users.  So I think the search needs to stop when it encounters multiple users of a StoreCM since that represents a split of control flow.  Thanks for catching that.
>>>>
>>>> Sounds like a job for partial redundancy elimination.
>>>>
>>>> tom
>>>>
>>>>> Vladimir
>>>>>
>>>>> Tom Rodriguez wrote:
>>>>>> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
>>>>>>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn) into locals before the loop. Also you need to kill the node explicitly otherwise it still be connected to its inputs:
>>>>>>>
>>>>>>> +         // Eliminate the previous StoreCM
>>>>>>> +         prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>>>> +         assert(mem->outcnt() == 0, "should be dead");
>>>>>>> +         mem->disconnect_inputs(NULL);
>>>>>> I'll have to rework the mem traversal a little.  Actually I think there might have been a bug with the old code since it always updated prev.  I believe this is correct:
>>>>>>       // Eliminate the previous StoreCM                                                                                                                     prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>>>       assert(mem->outcnt() == 0, "should be dead");
>>>>>>       mem->disconnect_inputs(NULL);
>>>>>>     } else {                                                                                                                                               prev = mem;                                                                                                                                         }
>>>>>>     mem = prev->in(MemNode::Memory);
>>>>>>   }
>>>>>> I think I'll put together a little test case to make sure this is working correctly.
>>>>>> tom
>>>>>>> Vladimir
>>>>>>>
>>>>>>> Tom Rodriguez wrote:
>>>>>>>> I could push this to hotspot-gc so it gets more CMS testing .
>>>>>>>> http://cr.openjdk.java.net/~never/7032963
>>>>>>>> 7032963: StoreCM shouldn't participate in store elimination
>>>>>>>> Reviewed-by:
>>>>>>>> StoreCM shouldn't participate in redundant store elimination since
>>>>>>>> that could violate the requirement that a StoreCM must be strictly
>>>>>>>> after a field update.  This results in a large number of redundant
>>>>>>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>>>>>>> optimization to fold them up safely.  Previously the extra dependence
>>>>>>>> was converted into a precedence edge just before register allocation
>>>>>>>> but I moved this logic into final_graph_reshape.  I then added logic
>>>>>>>> to search through chains of StoreCMs to eliminate earlier redundant
>>>>>>>> ones and transfer their precedence edges to the one that is kept.
>>>>>>>> This ensures that they are scheduled properly.  This actually
>>>>>>>> eliminates duplicates that were previously missed so the code quality
>>>>>>>> is slightly better.  Tested by inspecting code generation with script
>>>>>>>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>>>>>>>> -XX:+UseG1GC.
> 

From tom.rodriguez at oracle.com  Sat Apr  2 05:46:40 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Sat, 02 Apr 2011 12:46:40 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 6909440: C2 fails with assertion
	(_always_cold->is_cold(), "must always be cold")
Message-ID: <20110402124643.30F9F4771B@hg.openjdk.java.net>

Changeset: f8b038506985
Author:    never
Date:      2011-04-01 21:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f8b038506985

6909440: C2 fails with assertion (_always_cold->is_cold(),"must always be cold")
Reviewed-by: kvn

! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp


From vladimir.kozlov at oracle.com  Sat Apr  2 11:55:57 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 02 Apr 2011 18:55:57 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7032314: Allow to generate
	CallLeafNoFPNode in IdealKit
Message-ID: <20110402185559.09B5447728@hg.openjdk.java.net>

Changeset: 07acc51c1d2a
Author:    kvn
Date:      2011-04-02 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07acc51c1d2a

7032314: Allow to generate CallLeafNoFPNode in IdealKit
Summary: Added CallLeafNoFPNode generation to IdealKit. Added i_o synchronization.
Reviewed-by: never

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/library_call.cpp


From vladimir.kozlov at oracle.com  Sat Apr  2 13:59:11 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 02 Apr 2011 20:59:11 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7004535: Clone loop predicate during
	loop unswitch
Message-ID: <20110402205913.CB9C94772D@hg.openjdk.java.net>

Changeset: 08eb13460b3a
Author:    kvn
Date:      2011-04-02 10:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/08eb13460b3a

7004535: Clone loop predicate during loop unswitch
Summary: Clone loop predicate for clonned loops
Reviewed-by: never

! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/ifnode.cpp
+ src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.hpp


From john.r.rose at oracle.com  Sat Apr  2 14:48:12 2011
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 2 Apr 2011 14:48:12 -0700
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110401143341.GG4281@redhat.com>
References: <20110401143341.GG4281@redhat.com>
Message-ID: <45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>

On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:

> Hi all,
> 
> This webrev adds support for JSR 292 to Zero:
> 
> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/

Most impressive!  I think this matches the following previously filed bug:

6829195  JSR 292 needs to support the C++ interpreter

Does this code pass the jtreg tests in jdk/test/java/lang/invoke/ ?

-- John

From rose00 at mac.com  Sat Apr  2 17:55:03 2011
From: rose00 at mac.com (John Rose)
Date: Sat, 02 Apr 2011 17:55:03 -0700
Subject: review request (XS): 6930553: classfile format checker allows invalid
	method descriptor in CONSTANT_NameAndType_info in some cases
Message-ID: <27E9BD75-C832-46E1-9110-E0078743AEFB@mac.com>

http://cr.openjdk.java.net/~jrose/6930553/webrev.00

From john.r.rose at oracle.com  Sat Apr  2 18:01:14 2011
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 2 Apr 2011 18:01:14 -0700
Subject: review request (S): 7024561: JSR 292 constant pool cache _f1 field
	doesn't get properly updated with parallel GC
Message-ID: <2BAD2735-D1DC-4A58-BDC6-F58061E9981F@oracle.com>

http://cr.openjdk.java.net/~jrose/7024561/webrev.00

From john.r.rose at oracle.com  Sat Apr  2 18:01:30 2011
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 2 Apr 2011 18:01:30 -0700
Subject: review request (S): 7012087: JSR 292 Misleading exception message for
	a non-bound MH for a virtual method
Message-ID: <9D80716D-FBAF-4983-8073-4B708FC31B63@oracle.com>

http://cr.openjdk.java.net/~jrose/7012087/webrev.00

From john.r.rose at oracle.com  Sat Apr  2 18:02:46 2011
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 2 Apr 2011 18:02:46 -0700
Subject: review request (S): 7012087: JSR 292 Misleading exception message for
	a non-bound MH for a virtual method
Message-ID: <A7081339-A244-4D41-8303-012FE36E27E9@oracle.com>

Error message formatting.  Multiple customers have stumbled over this.

  http://cr.openjdk.java.net/~jrose/7012087/webrev.00/

-- John


From roland.westrelin at oracle.com  Sun Apr  3 09:17:01 2011
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Sun, 03 Apr 2011 16:17:01 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7033154: Improve C1 arraycopy
	performance
Message-ID: <20110403161703.A64444775D@hg.openjdk.java.net>

Changeset: 13bc79b5c9c8
Author:    roland
Date:      2011-04-03 12:00 +0200
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/13bc79b5c9c8

7033154: Improve C1 arraycopy performance
Summary: better static analysis. Take advantage of array copy stubs.
Reviewed-by: never

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp


From vladimir.kozlov at oracle.com  Sun Apr  3 09:29:09 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sun, 03 Apr 2011 09:29:09 -0700
Subject: review request (XS): 6930553: classfile format checker allows
	invalid method descriptor in CONSTANT_NameAndType_info in some cases
In-Reply-To: <27E9BD75-C832-46E1-9110-E0078743AEFB@mac.com>
References: <27E9BD75-C832-46E1-9110-E0078743AEFB@mac.com>
Message-ID: <4D98A055.4080900@oracle.com>

Good.

Vladimir

On 4/2/11 5:55 PM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/6930553/webrev.00

From vladimir.kozlov at oracle.com  Sun Apr  3 09:32:16 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sun, 03 Apr 2011 09:32:16 -0700
Subject: review request (S): 7024561: JSR 292 constant pool cache _f1
	field doesn't get properly updated with parallel GC
In-Reply-To: <2BAD2735-D1DC-4A58-BDC6-F58061E9981F@oracle.com>
References: <2BAD2735-D1DC-4A58-BDC6-F58061E9981F@oracle.com>
Message-ID: <4D98A110.602@oracle.com>

Looks good.

Vladimir

On 4/2/11 6:01 PM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7024561/webrev.00

From vladimir.kozlov at oracle.com  Sun Apr  3 09:45:01 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sun, 03 Apr 2011 09:45:01 -0700
Subject: review request (S): 7012087: JSR 292 Misleading exception message
	for a non-bound MH for a virtual method
In-Reply-To: <A7081339-A244-4D41-8303-012FE36E27E9@oracle.com>
References: <A7081339-A244-4D41-8303-012FE36E27E9@oracle.com>
Message-ID: <4D98A40D.1030902@oracle.com>

1739     if ((dmf_flags &~ (MethodHandles::_dmf_has_receiver |
                         ^ better '& ~('
1740                        MethodHandles::_dmf_does_dispatch |
1741                        MethodHandles::_dmf_from_interface |  <<<<<<< duplicated
1742                        MethodHandles::_dmf_from_interface)) != 0)


has_receiver is set using different checks, may add an assert that they have the same result:

1744     bool has_receiver = ((dmf_flags & MethodHandles::_dmf_has_receiver) != 0);
1745     if (actual_method != NULL) {
1746       has_receiver = (!actual_method->is_static());

Vladimir

On 4/2/11 6:02 PM, John Rose wrote:
> Error message formatting.  Multiple customers have stumbled over this.
>
>    http://cr.openjdk.java.net/~jrose/7012087/webrev.00/
>
> -- John
>

From dmdabbs at gmail.com  Sun Apr  3 15:39:11 2011
From: dmdabbs at gmail.com (David Dabbs)
Date: Sun, 3 Apr 2011 17:39:11 -0500
Subject: review for 6385687: UseFastEmptyMethods/UseFastAccessorMethods
	considered harmful
In-Reply-To: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com>
References: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com>
Message-ID: <007f01cbf24f$f4b87aa0$de296fe0$@com>


> -----Original Message-----
> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-
> compiler-dev-bounces at openjdk.java.net] On Behalf Of Tom Rodriguez
> Sent: Wednesday, March 30, 2011 6:47 PM
> To: hotspot compiler
> Subject: review for 6385687: UseFastEmptyMethods/UseFastAccessorMethods
> considered harmful
> 
> http://cr.openjdk.java.net/~never/6385687
> 
> 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful
> Reviewed-by:
> 
> While running various benchmarks, it was noticed that the use of
> UseFastEmptyMethods/UseFastAccessorMethods can cause us to skip
> compiling these methods because the fast versions don't have
> invocation counters.  This can create severe performance anomalies if
> the empty or accessor methods don't get inlined since we'll always
> transition to the interpreter to execute this trivial code.  This
> commonly occurs at call sites that are truly polymorphic.  We could
> conceivably add invocation counter updates to these methods but that
> simply makes them less fast and requires more changes.  So it's more
> straightforward to simply disable them by default.  We could turn them
> on for -Xint mode or we could delete the fast accessor machinery
> completely.  It really only helps with raw interpreter performance.
> Tested with jbb and grindermark.



If these options really only help raw interpreter performance and they 
will soon be disabled by default, is there any reason NOT to disable them
now
for performance-oriented (i.e. -server C2) application code running
under JDK6? 


Thank you,

David



From gbenson at redhat.com  Mon Apr  4 01:23:21 2011
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 4 Apr 2011 09:23:21 +0100
Subject: UseFastEmptyMethods/UseFastAccessorMethods considered harmful
In-Reply-To: <20C6AF91-AED6-40D1-8821-9FABC9F19C92@oracle.com>
References: <20110401085745.94F62476BC@hg.openjdk.java.net>
	<20110401093931.GB4281@redhat.com>
	<20C6AF91-AED6-40D1-8821-9FABC9F19C92@oracle.com>
Message-ID: <20110404082321.GB3348@redhat.com>

Tom Rodriguez wrote:
> On Apr 1, 2011, at 2:39 AM, Gary Benson wrote:
> > I just spotted that UseFastEmptyMethods and UseFastAccessorMethods
> > are now off by default.  Zero and Shark both benefit hugely from
> > having these on, especially for accessors.  Would it be possible
> > to make it platform-specific somehow?
> 
> I had considered turning them on in interpreter only mode but that
> wouldn't help Shark.  Maybe I should restore the default and just
> turn them off in Arguments::set_mode_flags for COMPILER1 ||
> COMPILER2.  Otherwise we'd need to made them product_pd which is
> kind of a pain.  I'll send out an updated review.

Thanks Tom.  FWIW the deal with Shark and inlining is that in Shark
will attempt to inline any method below a certain size, regardless of
hotness, and accessors easily fally below that threshold.  It's not a
full inliner as such, but any inlining is useful for Shark as method
calls have a lot of overhead.  Also, the code generation phase (ie in
LLVM) takes much longer than the IR generation phase (it's like 90%+
of each compile) so Shark can afford to do some fairly involved
analysis for relatively little penalty.

Cheers,
Gary

-- 
http://gbenson.net/

From gbenson at redhat.com  Mon Apr  4 01:34:59 2011
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 4 Apr 2011 09:34:59 +0100
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
Message-ID: <20110404083459.GC3348@redhat.com>

John Rose wrote:
> On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
> > This webrev adds support for JSR 292 to Zero:
> > 
> > http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
> 
> Most impressive!  I think this matches the following previously
> filed bug:
> 
> 6829195  JSR 292 needs to support the C++ interpreter

Partially, yes, in that it implements invokedynamic and fast_aldc*
in the bytecode interpreter.  For the sparc or x86 ports you would
also need to write the method handle entries and add frame manager
support for the call_method_handle message.

> Does this code pass the jtreg tests in jdk/test/java/lang/invoke/ ?

It passed their previous incarnation in jdk/test/java/dyn, with
this webrev applied to stop the tests disabling themselves:

  http://cr.openjdk.java.net/~gbenson/zero-jsr292-tests/

I started updating my OpenJDK build on Friday to one with the most
recent tests but something failed in langtools and I didn't have
time to figure it out.  (FWIW this was an amd64 build, not Zero).
I'm going to try from a different forest today to see if I can get
a build I can test against.

Cheers,
Gary

-- 
http://gbenson.net/

From christian.thalinger at oracle.com  Mon Apr  4 04:18:01 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 4 Apr 2011 13:18:01 +0200
Subject: review request (S): 7024561: JSR 292 constant pool cache _f1
	field doesn't get properly updated with parallel GC
In-Reply-To: <2BAD2735-D1DC-4A58-BDC6-F58061E9981F@oracle.com>
References: <2BAD2735-D1DC-4A58-BDC6-F58061E9981F@oracle.com>
Message-ID: <57442EE2-649F-407D-9D96-BD129A5A7842@oracle.com>

On Apr 3, 2011, at 3:01 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7024561/webrev.00

I already reviewed it internally but just FTR:  this looks good.

-- Christian

From christian.thalinger at oracle.com  Mon Apr  4 05:17:50 2011
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Mon, 04 Apr 2011 12:17:50 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7032458: Zero and Shark fixes
Message-ID: <20110404121755.A69B04778D@hg.openjdk.java.net>

Changeset: e863062e521d
Author:    twisti
Date:      2011-04-04 03:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e863062e521d

7032458: Zero and Shark fixes
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/globals_zero.hpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/share/vm/ci/ciTypeFlow.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkCompiler.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp


From tom.rodriguez at oracle.com  Mon Apr  4 10:24:27 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 10:24:27 -0700
Subject: review for 6385687: UseFastEmptyMethods/UseFastAccessorMethods
	considered harmful
In-Reply-To: <007f01cbf24f$f4b87aa0$de296fe0$@com>
References: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com>
	<007f01cbf24f$f4b87aa0$de296fe0$@com>
Message-ID: <33ED513A-C8CE-43F5-9015-4A73F98980E5@oracle.com>

>> 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful
>> Reviewed-by:
>> 
>> While running various benchmarks, it was noticed that the use of
>> UseFastEmptyMethods/UseFastAccessorMethods can cause us to skip
>> compiling these methods because the fast versions don't have
>> invocation counters.  This can create severe performance anomalies if
>> the empty or accessor methods don't get inlined since we'll always
>> transition to the interpreter to execute this trivial code.  This
>> commonly occurs at call sites that are truly polymorphic.  We could
>> conceivably add invocation counter updates to these methods but that
>> simply makes them less fast and requires more changes.  So it's more
>> straightforward to simply disable them by default.  We could turn them
>> on for -Xint mode or we could delete the fast accessor machinery
>> completely.  It really only helps with raw interpreter performance.
>> Tested with jbb and grindermark.
> 
> 
> 
> If these options really only help raw interpreter performance and they 
> will soon be disabled by default, is there any reason NOT to disable them
> now
> for performance-oriented (i.e. -server C2) application code running
> under JDK6? 

It's really just a performance anomaly that we're trying to avoid.  If you are hitting this problem then by all means use the flag but don't bother if you aren't.  My general recommendation is not to be too flag happy, even though it's sometimes required for tuning.  Use the flags you need and no more.

tom

> 
> 
> Thank you,
> 
> David
> 
> 


From john.r.rose at oracle.com  Mon Apr  4 14:59:46 2011
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 4 Apr 2011 14:59:46 -0700
Subject: review request (S): 7012087: JSR 292 Misleading exception message
	for a non-bound MH for a virtual method
In-Reply-To: <4D98A40D.1030902@oracle.com>
References: <A7081339-A244-4D41-8303-012FE36E27E9@oracle.com>
	<4D98A40D.1030902@oracle.com>
Message-ID: <30C91E5F-F284-4586-88DC-3514E3DC23C1@oracle.com>

On Apr 3, 2011, at 9:45 AM, Vladimir Kozlov wrote:

> 1739     if ((dmf_flags &~ (MethodHandles::_dmf_has_receiver |
>                        ^ better '& ~('
> 1740                        MethodHandles::_dmf_does_dispatch |
> 1741                        MethodHandles::_dmf_from_interface |  <<<<<<< duplicated
> 1742                        MethodHandles::_dmf_from_interface)) != 0)

Thanks.  (I personally think of &~ as a single operator, but I try to keep it out of my code.)

> has_receiver is set using different checks, may add an assert that they have the same result:
> 
> 1744     bool has_receiver = ((dmf_flags & MethodHandles::_dmf_has_receiver) != 0);
> 1745     if (actual_method != NULL) {
> 1746       has_receiver = (!actual_method->is_static());

Good point.  I deleted the second assignment to has_receiver, and changed the mhArity computation to be self-contained:

+      mhArity = ArgumentCount(actual_method->signature()).size();
+      if (!actual_method->is_static())  mhArity += 1;

(Should I use ?: still?)

-- John

> Vladimir
> 
> On 4/2/11 6:02 PM, John Rose wrote:
>> Error message formatting.  Multiple customers have stumbled over this.
>> 
>>   http://cr.openjdk.java.net/~jrose/7012087/webrev.00/
>> 
>> -- John
>> 


From vladimir.kozlov at oracle.com  Mon Apr  4 15:01:44 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 15:01:44 -0700
Subject: review(S) 7004547: regular loop unroll should not unroll more than
	max unrolling
In-Reply-To: <4D939D71.3020908@oracle.com>
References: <4D939D71.3020908@oracle.com>
Message-ID: <4D9A3FC8.2080206@oracle.com>

http://cr.openjdk.java.net/~kvn/7004547/webrev

Fixed 7004547: regular loop unroll should not unroll more than max unrolling

Max unroll policy when calculating new loop body size does not take into account 
that after unroll conjoined loop's head and tail will fold. As result there are 
cases when max unroll was not done but regular unroll will do full unrolling for 
main loop.
Use long arithmetic to calculate exact trip count.
Add missing nodes limit check for loop split (pre-main-post).


From igor.veresov at oracle.com  Mon Apr  4 15:37:52 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 04 Apr 2011 15:37:52 -0700
Subject: review(XS) 7033732: C1: When calling c2 arraycopy stubs offsets and
	length must have clear upper 32bits
Message-ID: <4D9A4840.40903@oracle.com>

With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9 
we must clear the upper 32bits for offset (src_pos, dst_pos) and length 
parameters when calling them.

Tested with failing nightlies.

Webrev: http://cr.openjdk.java.net/~iveresov/7033732/webrev.00/

igor

From tom.rodriguez at oracle.com  Mon Apr  4 15:40:17 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 15:40:17 -0700
Subject: review(XS) 7033732: C1: When calling c2 arraycopy stubs offsets
	and length must have clear upper 32bits
In-Reply-To: <4D9A4840.40903@oracle.com>
References: <4D9A4840.40903@oracle.com>
Message-ID: <E6AF46C7-F486-4BB1-9FC7-97E1DDEBBB4E@oracle.com>

Looks good.  Thanks for fixing this.

tom

On Apr 4, 2011, at 3:37 PM, Igor Veresov wrote:

> With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9 we must clear the upper 32bits for offset (src_pos, dst_pos) and length parameters when calling them.
> 
> Tested with failing nightlies.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/7033732/webrev.00/
> 
> igor


From vladimir.kozlov at oracle.com  Mon Apr  4 15:40:37 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 15:40:37 -0700
Subject: review request (S): 7012087: JSR 292 Misleading exception message
	for a non-bound MH for a virtual method
In-Reply-To: <30C91E5F-F284-4586-88DC-3514E3DC23C1@oracle.com>
References: <A7081339-A244-4D41-8303-012FE36E27E9@oracle.com>
	<4D98A40D.1030902@oracle.com>
	<30C91E5F-F284-4586-88DC-3514E3DC23C1@oracle.com>
Message-ID: <4D9A48E5.8080604@oracle.com>

John Rose wrote:
> 1741                        MethodHandles::_dmf_from_interface |  <<<<<<< duplicated

Did you remove duplicate?

> 1742                        MethodHandles::_dmf_from_interface)) != 0)
> 
>> has_receiver is set using different checks, may add an assert that they have the same result:
>>
>> 1744     bool has_receiver = ((dmf_flags & MethodHandles::_dmf_has_receiver) != 0);
>> 1745     if (actual_method != NULL) {
>> 1746       has_receiver = (!actual_method->is_static());
> 
> Good point.  I deleted the second assignment to has_receiver, and changed the mhArity computation to be self-contained:
> 
> +      mhArity = ArgumentCount(actual_method->signature()).size();
> +      if (!actual_method->is_static())  mhArity += 1;

This code is fine, don't need "?:".

Vladimir

> 
> (Should I use ?: still?)
> 
> -- John
> 
>> Vladimir
>>
>> On 4/2/11 6:02 PM, John Rose wrote:
>>> Error message formatting.  Multiple customers have stumbled over this.
>>>
>>>   http://cr.openjdk.java.net/~jrose/7012087/webrev.00/
>>>
>>> -- John
>>>
> 

From vladimir.kozlov at oracle.com  Mon Apr  4 15:41:28 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 15:41:28 -0700
Subject: review(XS) 7033732: C1: When calling c2 arraycopy stubs offsets
	and length must have clear upper 32bits
In-Reply-To: <4D9A4840.40903@oracle.com>
References: <4D9A4840.40903@oracle.com>
Message-ID: <4D9A4918.8090102@oracle.com>

Good.

Vladimir

Igor Veresov wrote:
> With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9 
> we must clear the upper 32bits for offset (src_pos, dst_pos) and length 
> parameters when calling them.
> 
> Tested with failing nightlies.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/7033732/webrev.00/
> 
> igor

From igor.veresov at oracle.com  Mon Apr  4 15:45:12 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 04 Apr 2011 15:45:12 -0700
Subject: review(XS) 7033732: C1: When calling c2 arraycopy stubs offsets
	and length must have clear upper 32bits
In-Reply-To: <4D9A4918.8090102@oracle.com>
References: <4D9A4840.40903@oracle.com> <4D9A4918.8090102@oracle.com>
Message-ID: <4D9A49F8.5030701@oracle.com>

Thanks Tom and Vladimir!

igor

On 4/4/11 3:41 PM, Vladimir Kozlov wrote:
> Good.
>
> Vladimir
>
> Igor Veresov wrote:
>> With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9
>> we must clear the upper 32bits for offset (src_pos, dst_pos) and
>> length parameters when calling them.
>>
>> Tested with failing nightlies.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/7033732/webrev.00/
>>
>> igor


From tom.rodriguez at oracle.com  Mon Apr  4 16:21:44 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 16:21:44 -0700
Subject: review (S) for 6777083: assert(target != __null,"must not be null")
Message-ID: <3157BB40-30FB-423F-ACFB-CC035B9F8F8B@oracle.com>

http://cr.openjdk.java.net/~never/6777083

6777083: assert(target != __null,"must not be null")
Reviewed-by:

ExternalAddress is often used to generate code for references to the
byte_map_base of the card table.  Depending on the address layout we
get byte_map_base may be a real address looking value or sometimes it
maybe a small number or even zero.  This causes
external_word_relocation to assert because the encoding it uses
assumes that the adress isn't within the first page.  This has been
patched up at each use site in the past but keeps recurring as new
code gets written.  To fix this I've modified ExternalAddress to drop
the reloc in the case where it's not encodable.  It's almost
impossible to force a layout where byte_map_base is a small number but
injecting a small number into it indicates that the assembly code
generation works correcty after the change.


From john.r.rose at oracle.com  Mon Apr  4 16:27:26 2011
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 4 Apr 2011 16:27:26 -0700
Subject: review request (S): 7012087: JSR 292 Misleading exception message
	for a non-bound MH for a virtual method
In-Reply-To: <4D9A48E5.8080604@oracle.com>
References: <A7081339-A244-4D41-8303-012FE36E27E9@oracle.com>
	<4D98A40D.1030902@oracle.com>
	<30C91E5F-F284-4586-88DC-3514E3DC23C1@oracle.com>
	<4D9A48E5.8080604@oracle.com>
Message-ID: <459B4DFE-971C-4214-A82E-70E844A27EC4@oracle.com>

On Apr 4, 2011, at 3:40 PM, Vladimir Kozlov wrote:

> John Rose wrote:
>> 1741                        MethodHandles::_dmf_from_interface |  <<<<<<< duplicated
> 
> Did you remove duplicate?

No; thanks for the poke.  Fixed now.  -- John

From john.cuthbertson at oracle.com  Mon Apr  4 16:43:16 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 04 Apr 2011 16:43:16 -0700
Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed:
	Error
In-Reply-To: <4D90C6E0.9000901@oracle.com>
References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com>
Message-ID: <4D9A5794.1030507@oracle.com>

Hi Everyone,

A new webrev for this fix can be found at: 
http://cr.openjdk.java.net/~johnc/7009266/webrev.5/

The changes in this revision include:

* Revised barrier set calls in JNI_GetObjectField and Unsafe_getObject 
so that the value that is returned is the value that gets recorded in an 
SATB buffer. The code in the previous revision re-read the value of the 
field potentially causing the value the is logged to be different from 
that returned.

* Added the static checks, suggested by Tom, in library_call.cpp.

* Removed the complicated control flow from the C1 LIR implementation of 
Unsafe.getObject. Instead the checks have been moved into a code stub 
while some static checks have been added.

* Re-enabled reference discovery (and therefore reference processing) 
during concurrent marking as a result of pushing the changes for 7020042 
to hs21.

Thanks,

JohnC

On 03/28/11 10:35, John Cuthbertson wrote:
> Hi Everyone,
>
> A new webrev with changes based upon comments from Tom can be found 
> at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/.
>
> The latest changes include inserting a suitably guarded barrier call 
> in case the referent field of a Reference object is being read/fetched 
> using JNI, reflection, or Unsafe.
>
> Thanks,
>
> JohnC
>
> On 3/11/2011 5:34 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> I'm looking for a few of volunteers to review the changes that fix 
>> this assertion failure. The latest changes can be found at: 
>> http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include 
>> changes based upon earlier internal reviews. The earlier changes are 
>> also on cr.openjdk.java.net for reference.
>>
>> Background:
>> The G1 garbage collector includes a concurrent marking algorithm that 
>> makes use of snapshot-at-the-beginning or SATB. With this algorithm 
>> the GC will mark all objects that are reachable at the start of 
>> marking; objects that are allocated since the start of marking are 
>> implicitly considered live. In order to populate the "snapshot" of 
>> the object graph that existed at the start of marking, G1 employs a 
>> write barrier. When an object is stored into another object's field 
>> the write-barrier records the previous value of that field as it was 
>> part of the "snapshot" and concurrent marking will trace the 
>> sub-graph that is reachable from this previous value.
>>
>> Unfortunately, in the presence of Reference objects, SATB might not 
>> be sufficient to mark a referent object as live. Consider that, at 
>> the start of marking, we have a weakly reachable object i.e. an 
>> object where the only pointer to that object. If the referent is 
>> obtained from the Reference object and stored to another object's 
>> field (making the referent now strongly reachable and hence live) the 
>> G1 write barrier will record the field's previous value but not the 
>> value of the referent.
>>
>> If the referent object is strongly reachable from some other object 
>> that will be traced by concurrent marking, _or_ there is a subsequent 
>> assignment to the field where we have written the referent (in which 
>> case we record the previous value - the referent - in an SATB buffer) 
>> then the referent will be marked live. Otherwise the referent will 
>> not be marked.
>>
>> That is the issue that was causing the failure in this CR. There was 
>> a Logger object that was only reachable through a WeakReference at 
>> the start of concurrent marking. During marking the Logger object is 
>> obtained from the WeakReference and stored into a field of a live 
>> object. The G1 write barrier recorded the previous value in the field 
>> (as it is part of the snapshot at the start of marking). Since there 
>> was no other assignment to the live object's field and there was no 
>> other strong reference to the Logger object, the Logger object was 
>> not marked. At the end of concurrent marking the Logger object was 
>> considered dead and the link between the WeakReference and the Logger 
>> was severed by clearing the referent field during reference processing.
>>
>> To solve this (entirely in Hotspot and causing a performance overhead 
>> for G1 only) it was decided that the best approach was to intrinsify 
>> the Reference.get() method in the JIT compilers and add new 
>> interpreter entry points so that the value in the referent field will 
>> be recorded in an SATB buffer by the G1 pre-barrier code.
>>
>> The changes for Zero and the C++ interpreters are place holder 
>> routines but should be straight forward to implement.
>>
>> None of the individual changes is large - they are just well 
>> distributed around the JVM. :)
>>
>> Testing: white box test; eyeballing the generated compiled and 
>> interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), 
>> sparc (32/64 bit), Xint, Xcomp (client and server), with and without 
>> G1; the GC test suite with and without G1; and jprt.
>>
>> Thanks and regards,
>>
>> JohnC
>


From tom.rodriguez at oracle.com  Mon Apr  4 16:53:04 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 16:53:04 -0700
Subject: review(S) 7004547: regular loop unroll should not unroll more
	than max unrolling
In-Reply-To: <4D9A3FC8.2080206@oracle.com>
References: <4D939D71.3020908@oracle.com> <4D9A3FC8.2080206@oracle.com>
Message-ID: <6033FB21-1818-421D-917E-56ECD6941779@oracle.com>

Looks good.

tom

On Apr 4, 2011, at 3:01 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/7004547/webrev
> 
> Fixed 7004547: regular loop unroll should not unroll more than max unrolling
> 
> Max unroll policy when calculating new loop body size does not take into account that after unroll conjoined loop's head and tail will fold. As result there are cases when max unroll was not done but regular unroll will do full unrolling for main loop.
> Use long arithmetic to calculate exact trip count.
> Add missing nodes limit check for loop split (pre-main-post).
> 


From tom.rodriguez at oracle.com  Mon Apr  4 17:10:37 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 17:10:37 -0700
Subject: review (XS) for 6528013: C1 CTW failure with -XX:+VerifyOops
	assert(allocates2(pc), "")
Message-ID: <8B07BE3A-D2B5-4F65-A8B5-B9313E00C214@oracle.com>

http://cr.openjdk.java.net/~never/6528013

6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"")
Reviewed-by:

Make sure we don't overflow the code buffer when emitting VerifyOops
code.  Tested with failing test from report.


From igor.veresov at oracle.com  Mon Apr  4 17:12:04 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 04 Apr 2011 17:12:04 -0700
Subject: review (S) for 6777083: assert(target != __null,"must not be
	null")
In-Reply-To: <3157BB40-30FB-423F-ACFB-CC035B9F8F8B@oracle.com>
References: <3157BB40-30FB-423F-ACFB-CC035B9F8F8B@oracle.com>
Message-ID: <4D9A5E54.4020001@oracle.com>

Looks good.

igor

On 4/4/11 4:21 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6777083
>
> 6777083: assert(target != __null,"must not be null")
> Reviewed-by:
>
> ExternalAddress is often used to generate code for references to the
> byte_map_base of the card table.  Depending on the address layout we
> get byte_map_base may be a real address looking value or sometimes it
> maybe a small number or even zero.  This causes
> external_word_relocation to assert because the encoding it uses
> assumes that the adress isn't within the first page.  This has been
> patched up at each use site in the past but keeps recurring as new
> code gets written.  To fix this I've modified ExternalAddress to drop
> the reloc in the case where it's not encodable.  It's almost
> impossible to force a layout where byte_map_base is a small number but
> injecting a small number into it indicates that the assembly code
> generation works correcty after the change.
>


From igor.veresov at oracle.com  Mon Apr  4 17:16:35 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 04 Apr 2011 17:16:35 -0700
Subject: review (XS) for 6528013: C1 CTW failure with -XX:+VerifyOops
	assert(allocates2(pc), "")
In-Reply-To: <8B07BE3A-D2B5-4F65-A8B5-B9313E00C214@oracle.com>
References: <8B07BE3A-D2B5-4F65-A8B5-B9313E00C214@oracle.com>
Message-ID: <4D9A5F63.5040203@oracle.com>

Looks good.

igor

On 4/4/11 5:10 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6528013
>
> 6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"")
> Reviewed-by:
>
> Make sure we don't overflow the code buffer when emitting VerifyOops
> code.  Tested with failing test from report.
>


From vladimir.kozlov at oracle.com  Mon Apr  4 17:17:32 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 17:17:32 -0700
Subject: review (S) for 6777083: assert(target != __null,"must not be
	null")
In-Reply-To: <3157BB40-30FB-423F-ACFB-CC035B9F8F8B@oracle.com>
References: <3157BB40-30FB-423F-ACFB-CC035B9F8F8B@oracle.com>
Message-ID: <4D9A5F9C.9020107@oracle.com>

The fix looks good. Do you know why we use ExternalAddress for byte_map_base on 
x86? On sparc it is just constant value (address).

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6777083
> 
> 6777083: assert(target != __null,"must not be null")
> Reviewed-by:
> 
> ExternalAddress is often used to generate code for references to the
> byte_map_base of the card table.  Depending on the address layout we
> get byte_map_base may be a real address looking value or sometimes it
> maybe a small number or even zero.  This causes
> external_word_relocation to assert because the encoding it uses
> assumes that the adress isn't within the first page.  This has been
> patched up at each use site in the past but keeps recurring as new
> code gets written.  To fix this I've modified ExternalAddress to drop
> the reloc in the case where it's not encodable.  It's almost
> impossible to force a layout where byte_map_base is a small number but
> injecting a small number into it indicates that the assembly code
> generation works correcty after the change.
> 

From vladimir.kozlov at oracle.com  Mon Apr  4 17:19:25 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 17:19:25 -0700
Subject: review(S) 7004547: regular loop unroll should not unroll more
	than max unrolling
In-Reply-To: <6033FB21-1818-421D-917E-56ECD6941779@oracle.com>
References: <4D939D71.3020908@oracle.com> <4D9A3FC8.2080206@oracle.com>
	<6033FB21-1818-421D-917E-56ECD6941779@oracle.com>
Message-ID: <4D9A600D.7000501@oracle.com>

Thanks.

Vladimir

Tom Rodriguez wrote:
> Looks good.
> 
> tom
> 
> On Apr 4, 2011, at 3:01 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/7004547/webrev
>>
>> Fixed 7004547: regular loop unroll should not unroll more than max unrolling
>>
>> Max unroll policy when calculating new loop body size does not take into account that after unroll conjoined loop's head and tail will fold. As result there are cases when max unroll was not done but regular unroll will do full unrolling for main loop.
>> Use long arithmetic to calculate exact trip count.
>> Add missing nodes limit check for loop split (pre-main-post).
>>
> 

From vladimir.kozlov at oracle.com  Mon Apr  4 17:21:26 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 17:21:26 -0700
Subject: review (XS) for 6528013: C1 CTW failure with -XX:+VerifyOops
	assert(allocates2(pc), "")
In-Reply-To: <8B07BE3A-D2B5-4F65-A8B5-B9313E00C214@oracle.com>
References: <8B07BE3A-D2B5-4F65-A8B5-B9313E00C214@oracle.com>
Message-ID: <4D9A6086.3050908@oracle.com>

Good.

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6528013
> 
> 6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"")
> Reviewed-by:
> 
> Make sure we don't overflow the code buffer when emitting VerifyOops
> code.  Tested with failing test from report.
> 

From tom.rodriguez at oracle.com  Mon Apr  4 17:25:08 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 17:25:08 -0700
Subject: review (S) for 6777083: assert(target != __null,
	"must not be null")
In-Reply-To: <4D9A5F9C.9020107@oracle.com>
References: <3157BB40-30FB-423F-ACFB-CC035B9F8F8B@oracle.com>
	<4D9A5F9C.9020107@oracle.com>
Message-ID: <18CABAA4-9A08-4FE3-9D28-E8E977994578@oracle.com>


On Apr 4, 2011, at 5:17 PM, Vladimir Kozlov wrote:

> The fix looks good. Do you know why we use ExternalAddress for byte_map_base on x86? On sparc it is just constant value (address).

I think it's an attempt to take advantage of rip relative addressing to produce the constant in 64 bit.  I played a bit with unifying all the copies of the card table assembly but I kind of rat holed on it.  It's just a bit of a mess and I felt myself getting sucked under so I got out of the water and went with the most straightforward fixed that made it go away.  ;)

tom

> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/6777083
>> 6777083: assert(target != __null,"must not be null")
>> Reviewed-by:
>> ExternalAddress is often used to generate code for references to the
>> byte_map_base of the card table.  Depending on the address layout we
>> get byte_map_base may be a real address looking value or sometimes it
>> maybe a small number or even zero.  This causes
>> external_word_relocation to assert because the encoding it uses
>> assumes that the adress isn't within the first page.  This has been
>> patched up at each use site in the past but keeps recurring as new
>> code gets written.  To fix this I've modified ExternalAddress to drop
>> the reloc in the case where it's not encodable.  It's almost
>> impossible to force a layout where byte_map_base is a small number but
>> injecting a small number into it indicates that the assembly code
>> generation works correcty after the change.


From tom.rodriguez at oracle.com  Mon Apr  4 18:45:12 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Tue, 05 Apr 2011 01:45:12 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7026957:
	assert(type2aelembytes(store->as_Mem()->memory_type(),
	true) == 1 << shift->in(2)->get_int()) failed
Message-ID: <20110405014517.F06E6477BE@hg.openjdk.java.net>

Changeset: 8b2317d732ec
Author:    never
Date:      2011-04-04 12:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b2317d732ec

7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed
Reviewed-by: kvn, jrose

! src/share/vm/opto/loopTransform.cpp


From tom.rodriguez at oracle.com  Mon Apr  4 18:55:21 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 18:55:21 -0700
Subject: review (XS) for 6528013: C1 CTW failure with -XX:+VerifyOops
	assert(allocates2(pc), "")
In-Reply-To: <4D9A6086.3050908@oracle.com>
References: <8B07BE3A-D2B5-4F65-A8B5-B9313E00C214@oracle.com>
	<4D9A6086.3050908@oracle.com>
Message-ID: <FA2D8D7B-F836-4661-BA00-BE4C958FCC58@oracle.com>

Thanks Vladimir and Igor.

tom

On Apr 4, 2011, at 5:21 PM, Vladimir Kozlov wrote:

> Good.
> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/6528013
>> 6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"")
>> Reviewed-by:
>> Make sure we don't overflow the code buffer when emitting VerifyOops
>> code.  Tested with failing test from report.


From tom.rodriguez at oracle.com  Mon Apr  4 19:08:05 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 19:08:05 -0700
Subject: review (XS) for 7033779: CodeCache::largest_free_block may need to
	hold the CodeCache lock
Message-ID: <694E7852-D097-499C-88DA-D493B167EA53@oracle.com>

http://cr.openjdk.java.net/~never/7033779

7033779: CodeCache::largest_free_block may need to hold the CodeCache lock
Reviewed-by:

CodeCache::largest_free_block may be called without the CodeCache_lock
being held which might result in crashes when the free list is being
updated.  The changes for 7025742 are the primary culprit but there
are other places where this was being done.  The fix is to acquire the
lock when needed.  I wasn't able to directly reproduce the original
crash so I just tested it by running the JVM a bit to make sure the
calls to largest_free_block continued to work correctly in both
contexts.


From vladimir.kozlov at oracle.com  Mon Apr  4 19:12:48 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 04 Apr 2011 19:12:48 -0700
Subject: review (XS) for 7033779: CodeCache::largest_free_block may need
	to hold the CodeCache lock
In-Reply-To: <694E7852-D097-499C-88DA-D493B167EA53@oracle.com>
References: <694E7852-D097-499C-88DA-D493B167EA53@oracle.com>
Message-ID: <4D9A7AA0.1020801@oracle.com>

Looks good. Thank you for fixing this.

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7033779
> 
> 7033779: CodeCache::largest_free_block may need to hold the CodeCache lock
> Reviewed-by:
> 
> CodeCache::largest_free_block may be called without the CodeCache_lock
> being held which might result in crashes when the free list is being
> updated.  The changes for 7025742 are the primary culprit but there
> are other places where this was being done.  The fix is to acquire the
> lock when needed.  I wasn't able to directly reproduce the original
> crash so I just tested it by running the JVM a bit to make sure the
> calls to largest_free_block continued to work correctly in both
> contexts.
> 

From igor.veresov at oracle.com  Mon Apr  4 19:43:11 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 04 Apr 2011 19:43:11 -0700
Subject: review (XS) for 7033779: CodeCache::largest_free_block may need
	to hold the CodeCache lock
In-Reply-To: <694E7852-D097-499C-88DA-D493B167EA53@oracle.com>
References: <694E7852-D097-499C-88DA-D493B167EA53@oracle.com>
Message-ID: <4D9A81BF.3070402@oracle.com>

Looks good.

igor

On 4/4/11 7:08 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7033779
>
> 7033779: CodeCache::largest_free_block may need to hold the CodeCache lock
> Reviewed-by:
>
> CodeCache::largest_free_block may be called without the CodeCache_lock
> being held which might result in crashes when the free list is being
> updated.  The changes for 7025742 are the primary culprit but there
> are other places where this was being done.  The fix is to acquire the
> lock when needed.  I wasn't able to directly reproduce the original
> crash so I just tested it by running the JVM a bit to make sure the
> calls to largest_free_block continued to work correctly in both
> contexts.
>


From tom.rodriguez at oracle.com  Mon Apr  4 19:45:31 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 4 Apr 2011 19:45:31 -0700
Subject: review (XS) for 7033779: CodeCache::largest_free_block may need
	to hold the CodeCache lock
In-Reply-To: <4D9A81BF.3070402@oracle.com>
References: <694E7852-D097-499C-88DA-D493B167EA53@oracle.com>
	<4D9A81BF.3070402@oracle.com>
Message-ID: <A2284C4F-BE97-4B52-85EC-6228407649AB@oracle.com>

Thanks Vladimir and Igor.

tom

On Apr 4, 2011, at 7:43 PM, Igor Veresov wrote:

> Looks good.
> 
> igor
> 
> On 4/4/11 7:08 PM, Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7033779
>> 
>> 7033779: CodeCache::largest_free_block may need to hold the CodeCache lock
>> Reviewed-by:
>> 
>> CodeCache::largest_free_block may be called without the CodeCache_lock
>> being held which might result in crashes when the free list is being
>> updated.  The changes for 7025742 are the primary culprit but there
>> are other places where this was being done.  The fix is to acquire the
>> lock when needed.  I wasn't able to directly reproduce the original
>> crash so I just tested it by running the JVM a bit to make sure the
>> calls to largest_free_block continued to work correctly in both
>> contexts.
>> 
> 


From igor.veresov at oracle.com  Mon Apr  4 20:50:24 2011
From: igor.veresov at oracle.com (igor.veresov at oracle.com)
Date: Tue, 05 Apr 2011 03:50:24 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20110405035028.78C01477C4@hg.openjdk.java.net>

Changeset: bb22629531fa
Author:    iveresov
Date:      2011-04-04 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bb22629531fa

7033732: C1: When calling c2 arraycopy stubs offsets and length must have clear upper 32bits
Summary: With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9 we must clear the upper 32bits for offset (src_pos, dst_pos) and length parameters when calling them.
Reviewed-by: never, kvn

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: a54519951ff6
Author:    iveresov
Date:      2011-04-04 18:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a54519951ff6

Merge



From tom.rodriguez at oracle.com  Tue Apr  5 00:24:23 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Tue, 05 Apr 2011 07:24:23 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20110405072430.92F1D477CE@hg.openjdk.java.net>

Changeset: 87ce328c6a21
Author:    never
Date:      2011-04-04 19:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87ce328c6a21

6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"")
Reviewed-by: kvn, iveresov

! src/share/vm/c1/c1_LIRAssembler.cpp

Changeset: fb37e3eabfd0
Author:    never
Date:      2011-04-04 22:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fb37e3eabfd0

Merge



From vladimir.kozlov at oracle.com  Tue Apr  5 02:28:27 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Tue, 05 Apr 2011 09:28:27 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20110405092833.B5315477D4@hg.openjdk.java.net>

Changeset: d7a3fed1c1c9
Author:    kvn
Date:      2011-04-04 19:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7a3fed1c1c9

7004547: regular loop unroll should not unroll more than max unrolling
Summary: Take into account that after unroll conjoined heads and tails will fold.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp

Changeset: 03f2be00fa21
Author:    kvn
Date:      2011-04-05 00:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/03f2be00fa21

Merge



From tom.rodriguez at oracle.com  Tue Apr  5 04:31:24 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Tue, 05 Apr 2011 11:31:24 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20110405113129.BE0AD477D9@hg.openjdk.java.net>

Changeset: 479b4b4b6950
Author:    never
Date:      2011-04-05 00:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/479b4b4b6950

6777083: assert(target != __null,"must not be null")
Reviewed-by: iveresov, kvn

! src/cpu/x86/vm/assembler_x86.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp

Changeset: 8e77e1f26188
Author:    never
Date:      2011-04-05 02:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8e77e1f26188

Merge



From christian.thalinger at oracle.com  Tue Apr  5 05:46:23 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 5 Apr 2011 14:46:23 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110401143341.GG4281@redhat.com>
References: <20110401143341.GG4281@redhat.com>
Message-ID: <67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>

On Apr 1, 2011, at 4:33 PM, Gary Benson wrote:
> Hi all,
> 
> This webrev adds support for JSR 292 to Zero:
> 
>  http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/

hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:

+    // NB the x86 code for this (in methodHandles_x86.cpp, search for
+    // "genericInvoker") is really really odd.  I'm hoping it's trying
+    // to accomodate odd VM/class library combinations I can ignore.

Do you mean the code around sorry_no_invoke_generic?

hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:

+          assert(false, "Should have thrown incompatible class change exception");

I'd use ShouldNotReachHere instead.

I have to say that I don't know very much about the C++ interpreter or Zero but the code looks good.  Most important is that the MethodHandlesTest passes.

-- Christian

> 
> Note that is is designed to apply after the fix for 7032458,
> which is currently under review and can be found here:
> 
>  http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-2/
> 
> I don't have a bug id for this.
> 
> Cheers,
> Gary




From christian.thalinger at oracle.com  Tue Apr  5 05:49:08 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 5 Apr 2011 14:49:08 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110404083459.GC3348@redhat.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
Message-ID: <D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>

On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
> John Rose wrote:
>> On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
>>> This webrev adds support for JSR 292 to Zero:
>>> 
>>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
>> 
>> Most impressive!  I think this matches the following previously
>> filed bug:
>> 
>> 6829195  JSR 292 needs to support the C++ interpreter
> 
> Partially, yes, in that it implements invokedynamic and fast_aldc*
> in the bytecode interpreter.  For the sparc or x86 ports you would
> also need to write the method handle entries and add frame manager
> support for the call_method_handle message.

How much work would that be?

> 
>> Does this code pass the jtreg tests in jdk/test/java/lang/invoke/ ?
> 
> It passed their previous incarnation in jdk/test/java/dyn, with
> this webrev applied to stop the tests disabling themselves:
> 
>  http://cr.openjdk.java.net/~gbenson/zero-jsr292-tests/

John, can you add that code with one of your changes?

-- Christian

> 
> I started updating my OpenJDK build on Friday to one with the most
> recent tests but something failed in langtools and I didn't have
> time to figure it out.  (FWIW this was an amd64 build, not Zero).
> I'm going to try from a different forest today to see if I can get
> a build I can test against.
> 
> Cheers,
> Gary




From gbenson at redhat.com  Tue Apr  5 06:46:16 2011
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 5 Apr 2011 14:46:16 +0100
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
	<D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
Message-ID: <20110405134616.GA3243@redhat.com>

Christian Thalinger wrote:
> On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
> > John Rose wrote:
> > > On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
> > > > This webrev adds support for JSR 292 to Zero:
> > > > 
> > > > http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
> > > 
> > > Most impressive!  I think this matches the following previously
> > > filed bug:
> > > 
> > > 6829195  JSR 292 needs to support the C++ interpreter
> > 
> > Partially, yes, in that it implements invokedynamic and fast_aldc*
> > in the bytecode interpreter.  For the sparc or x86 ports you would
> > also need to write the method handle entries and add frame manager
> > support for the call_method_handle message.
> 
> How much work would that be?

I'm not sure.  Actually, thinking about it, the method handle entries
are already there (the template and C++ interpreters have the same
ABI, no?)  You could check by trying to run the method handles tests.
If that's the case, the only extra bit is adding support for
call_method_handle.  There's a potential trap, however, in that the
calls to InterpreterRuntime::resolve_invokedynamic and
InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run enter VM
mode and end up reentering the C++ interpreter.  I don't know that the
assembly language ports can handle this.  They're certainly written to
avoid it, but that might be simply because BytecodeInterpreter::run
has a huge stack frame and they didn't want too many of those on the
stack.  If it is a problem I have some partially written code that
would work around this but once I realised Zero didn't need it I
stopped working on it.

Cheers,
Gary

-- 
http://gbenson.net/

From gbenson at redhat.com  Tue Apr  5 07:04:56 2011
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 5 Apr 2011 15:04:56 +0100
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>
Message-ID: <20110405140455.GB3243@redhat.com>

Christian Thalinger wrote:
> On Apr 1, 2011, at 4:33 PM, Gary Benson wrote:
> > This webrev adds support for JSR 292 to Zero:
> > 
> >  http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
> 
> hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:
> 
> +    // NB the x86 code for this (in methodHandles_x86.cpp, search for
> +    // "genericInvoker") is really really odd.  I'm hoping it's trying
> +    // to accomodate odd VM/class library combinations I can ignore.
> 
> Do you mean the code around sorry_no_invoke_generic?

Yeah, this bit:

  // load up an adapter from the calling type (Java weaves this)
  __ load_heap_oop(rdx_temp, Address(rax_mtype, __ delayed_value(java_lang_invoke_MethodType::form_offset_in_bytes, rdi_temp)));
  Register rdx_adapter = rdx_temp;
  // __ load_heap_oop(rdx_adapter, Address(rdx_temp, java_lang_invoke_MethodTypeForm::genericInvoker_offset_in_bytes()));
  // deal with old JDK versions:
  __ lea(rdi_temp, Address(rdx_temp, __ delayed_value(java_lang_invoke_MethodTypeForm::genericInvoker_offset_in_bytes, rdi_temp)));
  __ cmpptr(rdi_temp, rdx_temp);
  Label sorry_no_invoke_generic;
  __ jcc(Assembler::below, sorry_no_invoke_generic);

What I did in Zero is the commented out line:

  oop adapter = java_lang_invoke_MethodTypeForm::genericInvoker(form);

The not commented-out bit looks like its C++ equivalent would be:

  if ((intptr_t) adapter < (intptr_t) form) {
    // what sorry_no_invoke_generic does
  }

but I couldn't get it to work.  What's it for?

> hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
> 
> +          assert(false, "Should have thrown incompatible class change exception");
> 
> I'd use ShouldNotReachHere instead.

That happens in a lot of places in BytecodeInterpreter::run.  How
about I make another webrev that changes them all?

Cheers,
Gary

-- 
http://gbenson.net/

From christian.thalinger at oracle.com  Tue Apr  5 07:23:20 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 5 Apr 2011 16:23:20 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110405140455.GB3243@redhat.com>
References: <20110401143341.GG4281@redhat.com>
	<67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>
	<20110405140455.GB3243@redhat.com>
Message-ID: <DF9718D1-F707-412F-8FD8-C2D3C9C34E55@oracle.com>

On Apr 5, 2011, at 4:04 PM, Gary Benson wrote:
> Christian Thalinger wrote:
>> On Apr 1, 2011, at 4:33 PM, Gary Benson wrote:
>>> This webrev adds support for JSR 292 to Zero:
>>> 
>>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
>> 
>> hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:
>> 
>> +    // NB the x86 code for this (in methodHandles_x86.cpp, search for
>> +    // "genericInvoker") is really really odd.  I'm hoping it's trying
>> +    // to accomodate odd VM/class library combinations I can ignore.
>> 
>> Do you mean the code around sorry_no_invoke_generic?
> 
> Yeah, this bit:
> 
>  // load up an adapter from the calling type (Java weaves this)
>  __ load_heap_oop(rdx_temp, Address(rax_mtype, __ delayed_value(java_lang_invoke_MethodType::form_offset_in_bytes, rdi_temp)));
>  Register rdx_adapter = rdx_temp;
>  // __ load_heap_oop(rdx_adapter, Address(rdx_temp, java_lang_invoke_MethodTypeForm::genericInvoker_offset_in_bytes()));
>  // deal with old JDK versions:
>  __ lea(rdi_temp, Address(rdx_temp, __ delayed_value(java_lang_invoke_MethodTypeForm::genericInvoker_offset_in_bytes, rdi_temp)));
>  __ cmpptr(rdi_temp, rdx_temp);
>  Label sorry_no_invoke_generic;
>  __ jcc(Assembler::below, sorry_no_invoke_generic);
> 
> What I did in Zero is the commented out line:
> 
>  oop adapter = java_lang_invoke_MethodTypeForm::genericInvoker(form);
> 
> The not commented-out bit looks like its C++ equivalent would be:
> 
>  if ((intptr_t) adapter < (intptr_t) form) {
>    // what sorry_no_invoke_generic does
>  }
> 
> but I couldn't get it to work.  What's it for?

I think this code can go away when we remove the transitional JSR 292 support.  Right, John?

> 
>> hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
>> 
>> +          assert(false, "Should have thrown incompatible class change exception");
>> 
>> I'd use ShouldNotReachHere instead.
> 
> That happens in a lot of places in BytecodeInterpreter::run.  How
> about I make another webrev that changes them all?

In the current version?  I only find one at line 1722.

-- Christian

From gbenson at redhat.com  Tue Apr  5 07:32:47 2011
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 5 Apr 2011 15:32:47 +0100
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <DF9718D1-F707-412F-8FD8-C2D3C9C34E55@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>
	<20110405140455.GB3243@redhat.com>
	<DF9718D1-F707-412F-8FD8-C2D3C9C34E55@oracle.com>
Message-ID: <20110405143247.GA4048@redhat.com>

Christian Thalinger wrote:
> On Apr 5, 2011, at 4:04 PM, Gary Benson wrote:
> > Christian Thalinger wrote:
> > > hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
> > > 
> > > +          assert(false, "Should have thrown incompatible class change exception");
> > > 
> > > I'd use ShouldNotReachHere instead.
> > 
> > That happens in a lot of places in BytecodeInterpreter::run.  How
> > about I make another webrev that changes them all?
> 
> In the current version?  I only find one at line 1722.

Oh, I thought there were more.  Since there's only one, how about I
make another webrev with all three changed?  I agree that a SNRH is
preferable to assert(false, ...

Cheers,
Gary

-- 
http://gbenson.net/

From christian.thalinger at oracle.com  Tue Apr  5 07:39:10 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 5 Apr 2011 16:39:10 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110405143247.GA4048@redhat.com>
References: <20110401143341.GG4281@redhat.com>
	<67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>
	<20110405140455.GB3243@redhat.com>
	<DF9718D1-F707-412F-8FD8-C2D3C9C34E55@oracle.com>
	<20110405143247.GA4048@redhat.com>
Message-ID: <C86CA3D1-85CA-4A7B-9125-4475AD8ED1C4@oracle.com>

On Apr 5, 2011, at 4:32 PM, Gary Benson wrote:
> Christian Thalinger wrote:
>> On Apr 5, 2011, at 4:04 PM, Gary Benson wrote:
>>> Christian Thalinger wrote:
>>>> hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
>>>> 
>>>> +          assert(false, "Should have thrown incompatible class change exception");
>>>> 
>>>> I'd use ShouldNotReachHere instead.
>>> 
>>> That happens in a lot of places in BytecodeInterpreter::run.  How
>>> about I make another webrev that changes them all?
>> 
>> In the current version?  I only find one at line 1722.
> 
> Oh, I thought there were more.  Since there's only one, how about I
> make another webrev with all three changed?  I agree that a SNRH is
> preferable to assert(false, ...

Sounds good to me.  -- Christian

From gbenson at redhat.com  Tue Apr  5 08:14:14 2011
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 5 Apr 2011 16:14:14 +0100
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <C86CA3D1-85CA-4A7B-9125-4475AD8ED1C4@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<67FF389D-2E24-42E0-BDC5-2255B64D2274@oracle.com>
	<20110405140455.GB3243@redhat.com>
	<DF9718D1-F707-412F-8FD8-C2D3C9C34E55@oracle.com>
	<20110405143247.GA4048@redhat.com>
	<C86CA3D1-85CA-4A7B-9125-4475AD8ED1C4@oracle.com>
Message-ID: <20110405151414.GA3234@redhat.com>

Christian Thalinger wrote:
> On Apr 5, 2011, at 4:32 PM, Gary Benson wrote:
> > Christian Thalinger wrote:
> > > On Apr 5, 2011, at 4:04 PM, Gary Benson wrote:
> > > > Christian Thalinger wrote:
> > > > > hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
> > > > > 
> > > > > +          assert(false, "Should have thrown incompatible class change exception");
> > > > > 
> > > > > I'd use ShouldNotReachHere instead.
> > > > 
> > > > That happens in a lot of places in BytecodeInterpreter::run.
> > > > How about I make another webrev that changes them all?
> > > 
> > > In the current version?  I only find one at line 1722.
> > 
> > Oh, I thought there were more.  Since there's only one, how about
> > I make another webrev with all three changed?  I agree that a SNRH
> > is preferable to assert(false, ...
> 
> Sounds good to me.  -- Christian

http://cr.openjdk.java.net/~gbenson/zero-jsr292-02/

Cheers,
Gary

-- 
http://gbenson.net/

From tom.rodriguez at oracle.com  Tue Apr  5 11:56:32 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 5 Apr 2011 11:56:32 -0700
Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed:
	Error
In-Reply-To: <4D9A5794.1030507@oracle.com>
References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com>
	<4D9A5794.1030507@oracle.com>
Message-ID: <48D28564-37FA-4DC7-A0C2-3531844EB152@oracle.com>

Looks good.

tom

On Apr 4, 2011, at 4:43 PM, John Cuthbertson wrote:

> Hi Everyone,
> 
> A new webrev for this fix can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.5/
> 
> The changes in this revision include:
> 
> * Revised barrier set calls in JNI_GetObjectField and Unsafe_getObject so that the value that is returned is the value that gets recorded in an SATB buffer. The code in the previous revision re-read the value of the field potentially causing the value the is logged to be different from that returned.
> 
> * Added the static checks, suggested by Tom, in library_call.cpp.
> 
> * Removed the complicated control flow from the C1 LIR implementation of Unsafe.getObject. Instead the checks have been moved into a code stub while some static checks have been added.
> 
> * Re-enabled reference discovery (and therefore reference processing) during concurrent marking as a result of pushing the changes for 7020042 to hs21.
> 
> Thanks,
> 
> JohnC
> 
> On 03/28/11 10:35, John Cuthbertson wrote:
>> Hi Everyone,
>> 
>> A new webrev with changes based upon comments from Tom can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/.
>> 
>> The latest changes include inserting a suitably guarded barrier call in case the referent field of a Reference object is being read/fetched using JNI, reflection, or Unsafe.
>> 
>> Thanks,
>> 
>> JohnC
>> 
>> On 3/11/2011 5:34 PM, John Cuthbertson wrote:
>>> Hi Everyone,
>>> 
>>> I'm looking for a few of volunteers to review the changes that fix this assertion failure. The latest changes can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include changes based upon earlier internal reviews. The earlier changes are also on cr.openjdk.java.net for reference.
>>> 
>>> Background:
>>> The G1 garbage collector includes a concurrent marking algorithm that makes use of snapshot-at-the-beginning or SATB. With this algorithm the GC will mark all objects that are reachable at the start of marking; objects that are allocated since the start of marking are implicitly considered live. In order to populate the "snapshot" of the object graph that existed at the start of marking, G1 employs a write barrier. When an object is stored into another object's field the write-barrier records the previous value of that field as it was part of the "snapshot" and concurrent marking will trace the sub-graph that is reachable from this previous value.
>>> 
>>> Unfortunately, in the presence of Reference objects, SATB might not be sufficient to mark a referent object as live. Consider that, at the start of marking, we have a weakly reachable object i.e. an object where the only pointer to that object. If the referent is obtained from the Reference object and stored to another object's field (making the referent now strongly reachable and hence live) the G1 write barrier will record the field's previous value but not the value of the referent.
>>> 
>>> If the referent object is strongly reachable from some other object that will be traced by concurrent marking, _or_ there is a subsequent assignment to the field where we have written the referent (in which case we record the previous value - the referent - in an SATB buffer) then the referent will be marked live. Otherwise the referent will not be marked.
>>> 
>>> That is the issue that was causing the failure in this CR. There was a Logger object that was only reachable through a WeakReference at the start of concurrent marking. During marking the Logger object is obtained from the WeakReference and stored into a field of a live object. The G1 write barrier recorded the previous value in the field (as it is part of the snapshot at the start of marking). Since there was no other assignment to the live object's field and there was no other strong reference to the Logger object, the Logger object was not marked. At the end of concurrent marking the Logger object was considered dead and the link between the WeakReference and the Logger was severed by clearing the referent field during reference processing.
>>> 
>>> To solve this (entirely in Hotspot and causing a performance overhead for G1 only) it was decided that the best approach was to intrinsify the Reference.get() method in the JIT compilers and add new interpreter entry points so that the value in the referent field will be recorded in an SATB buffer by the G1 pre-barrier code.
>>> 
>>> The changes for Zero and the C++ interpreters are place holder routines but should be straight forward to implement.
>>> 
>>> None of the individual changes is large - they are just well distributed around the JVM. :)
>>> 
>>> Testing: white box test; eyeballing the generated compiled and interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), sparc (32/64 bit), Xint, Xcomp (client and server), with and without G1; the GC test suite with and without G1; and jprt.
>>> 
>>> Thanks and regards,
>>> 
>>> JohnC
>> 
> 


From tom.rodriguez at oracle.com  Tue Apr  5 15:09:39 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 5 Apr 2011 15:09:39 -0700
Subject: review for 7032963: StoreCM shouldn't participate in store
	elimination
In-Reply-To: <4D964E14.7040405@oracle.com>
References: <9D6B4DC5-E378-40DD-ADB0-F95AECF23A8D@oracle.com>
	<4D964E14.7040405@oracle.com>
Message-ID: <41D4D88B-6059-4720-8373-9DA7E269F936@oracle.com>


On Apr 1, 2011, at 3:13 PM, Y. Srinivas Ramakrishna wrote:

> On 4/1/2011 2:55 PM, Tom Rodriguez wrote:
>> I could push this to hotspot-gc so it gets more CMS testing .
> 
> That would be a very good idea (CMS as well as G1 testing, actually)!
> 
> I can't review your changes, lacking sufficient bkgrd or
> familiarity with the code, but ...

So I was going to push this to hotspot-gc.  Is that ok?  It won't make nightly testing tonight...

tom

> 
>> This actually
>>> eliminates duplicates that were previously missed so the code quality
>>> is slightly better.
> 
> wow! What more could one ask for --you fixed a correctness
> bug _and_ got us a bit more performance. Hmm, by chance does
> the fix also come with a free bottle of beer for all of us? ;-)
> 
> -- ramki
> 
>> 
>> http://cr.openjdk.java.net/~never/7032963
>> 
>> 7032963: StoreCM shouldn't participate in store elimination
>> Reviewed-by:
>> 
>> StoreCM shouldn't participate in redundant store elimination since
>> that could violate the requirement that a StoreCM must be strictly
>> after a field update.  This results in a large number of redundant
>> StoreCMs being emitted for blocks of fields updates, so I added an
>> optimization to fold them up safely.  Previously the extra dependence
>> was converted into a precedence edge just before register allocation
>> but I moved this logic into final_graph_reshape.  I then added logic
>> to search through chains of StoreCMs to eliminate earlier redundant
>> ones and transfer their precedence edges to the one that is kept.
>> This ensures that they are scheduled properly.  This actually
>> eliminates duplicates that were previously missed so the code quality
>> is slightly better.  Tested by inspecting code generation with script
>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>> -XX:+UseG1GC.
>> 
> 


From vitalyd at gmail.com  Tue Apr  5 22:35:50 2011
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 6 Apr 2011 01:35:50 -0400
Subject: support for SIMD in Hotspot (c2)
Message-ID: <BANLkTimn2+N7BWanX3M8FZgZdeatt4prFw@mail.gmail.com>

Hi guys,

Are there any current plans to support SIMD SSE/AVX vector ops in c2 (i.e.
loop vectorization transforms)? I came across a few related Oracle(Sun) RFEs
in the database, saw the superword.hpp/cpp source in the OpenJDK repository,
and did a bit of googl'ing but cannot tell where this stands at the moment.

Thanks,

Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110406/d5cf8e92/attachment.html 

From tom.rodriguez at oracle.com  Wed Apr  6 01:13:49 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Wed, 06 Apr 2011 08:13:49 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7033779: CodeCache::largest_free_block
	may need to hold the CodeCache lock
Message-ID: <20110406081351.D723D47831@hg.openjdk.java.net>

Changeset: 527977d4f740
Author:    never
Date:      2011-04-05 19:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/527977d4f740

7033779: CodeCache::largest_free_block may need to hold the CodeCache lock
Reviewed-by: kvn

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp


From vladimir.kozlov at oracle.com  Wed Apr  6 12:24:07 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 06 Apr 2011 12:24:07 -0700
Subject: Request for reviews (M): 7004555: Add new policy for one iteration
	loops
Message-ID: <4D9CBDD7.2040608@oracle.com>

http://cr.openjdk.java.net/~kvn/7004555/webrev

Fixed 7004555: Add new policy for one iteration loops

Add new policy for one iteration loops (mostly formal pre- loops) to fold exit 
condition and avoid going through do_maximally_unroll() as we do currently for 
such cases.
Move exact trip count calculation from policy_maximally_unroll() into separate 
method. Note, trip_count type is changed to unsigned int and its range is 
changed to [0, max_juint). Add new flag HasExactTripCount to indicate that 
loop's limits and trip count are constants.
Check for non overlaping init and limit values to avoid zero trip guard 
generation in remove_empty_loop.
Rename some CountedLoopNode flags.
Print loop iv range for counted loops dumps:

Loop: N286/N193  predicated counted [0,2),+1

From tom.rodriguez at oracle.com  Wed Apr  6 13:04:35 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 6 Apr 2011 13:04:35 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
Message-ID: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>

http://cr.openjdk.java.net/~never/7032162

7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
Reviewed-by:

This appears to be an existing problem with OptimizeStringConcat where
missing control can allow some loads to be split up to where their
base is NULL which causes addresses that can't be analyzed.  The fix
is to use the appropriate control.  If it's truly unneeded it will be
optimized away.  The bug was exposed by the String not in perm changes
because we were no longer treating some constant strings as embeddable
constants.  This is fixed by handling them specially in push_constant.
Tested with failing test from report and full CTW with string opts.


From vladimir.kozlov at oracle.com  Wed Apr  6 13:49:15 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 06 Apr 2011 13:49:15 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
In-Reply-To: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
References: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
Message-ID: <4D9CD1CB.6060108@oracle.com>

You replaced 'require_constant' with 'true' to the call make_from_constant() so 
I was wondering if it may change behavior. Specifically it may produce NULL now
if oop_constant->can_be_constant() is 'false':

       if (require_constant) {
         if (!o->can_be_constant())  return NULL;

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7032162
> 
> 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
> Reviewed-by:
> 
> This appears to be an existing problem with OptimizeStringConcat where
> missing control can allow some loads to be split up to where their
> base is NULL which causes addresses that can't be analyzed.  The fix
> is to use the appropriate control.  If it's truly unneeded it will be
> optimized away.  The bug was exposed by the String not in perm changes
> because we were no longer treating some constant strings as embeddable
> constants.  This is fixed by handling them specially in push_constant.
> Tested with failing test from report and full CTW with string opts.
> 

From tom.rodriguez at oracle.com  Wed Apr  6 14:04:19 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 6 Apr 2011 14:04:19 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
In-Reply-To: <4D9CD1CB.6060108@oracle.com>
References: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
	<4D9CD1CB.6060108@oracle.com>
Message-ID: <CC3EAA09-A1B8-4CB7-B1D4-02379BFFD1C6@oracle.com>


On Apr 6, 2011, at 1:49 PM, Vladimir Kozlov wrote:

> You replaced 'require_constant' with 'true' to the call make_from_constant() so I was wondering if it may change behavior. Specifically it may produce NULL now
> if oop_constant->can_be_constant() is 'false':
> 
>      if (require_constant) {
>        if (!o->can_be_constant())  return NULL;

In the !JavaObjectInPerm world Strings should always return true for can_be_constant.  Actually I think it would be better to fix it by changing ciObject::should_be_constant instead of just patching that use. I also included Classes in the test for consistency with the old behaviour.  So I've removed the changes in parse3.cpp and done this instead.

diff -r 8e77e1f26188 src/share/vm/ci/ciObject.cpp                                                                                                     
--- a/src/share/vm/ci/ciObject.cpp                                                                                                                   
+++ b/src/share/vm/ci/ciObject.cpp                                                                                                                   
@@ -194,6 +194,16 @@ bool ciObject::can_be_constant() {
 // ciObject::should_be_constant()                                                                                                                   
 bool ciObject::should_be_constant() {                                                                                                               
   if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                                   
+  if (!JavaObjectsInPerm) {                                                                                                                         
+    // We want Strings and Classes to be embeddable by default since                                                                                 
+    // they used to be in the perm world.  Not all Strings used to be                                                                               
+    // embeddable but there's no easy way to distinguish the interned                                                                               
+    // from the regulars ones so just treat them all that way.                                                                                       
+    ciEnv* env = CURRENT_ENV;                                                                                                                       
+    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                           
+      return true;                                                                                                                                   
+    }                                                                                                                                               
+  }                                                                                                                                                 
   return handle() == NULL || !is_scavengable();                                                                                                     
 }

tom

> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7032162
>> 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
>> Reviewed-by:
>> This appears to be an existing problem with OptimizeStringConcat where
>> missing control can allow some loads to be split up to where their
>> base is NULL which causes addresses that can't be analyzed.  The fix
>> is to use the appropriate control.  If it's truly unneeded it will be
>> optimized away.  The bug was exposed by the String not in perm changes
>> because we were no longer treating some constant strings as embeddable
>> constants.  This is fixed by handling them specially in push_constant.
>> Tested with failing test from report and full CTW with string opts.


From vladimir.kozlov at oracle.com  Wed Apr  6 14:07:08 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 06 Apr 2011 14:07:08 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
In-Reply-To: <CC3EAA09-A1B8-4CB7-B1D4-02379BFFD1C6@oracle.com>
References: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
	<4D9CD1CB.6060108@oracle.com>
	<CC3EAA09-A1B8-4CB7-B1D4-02379BFFD1C6@oracle.com>
Message-ID: <4D9CD5FC.4090202@oracle.com>

This looks better.

Thanks,
Vladimir

Tom Rodriguez wrote:
> On Apr 6, 2011, at 1:49 PM, Vladimir Kozlov wrote:
> 
>> You replaced 'require_constant' with 'true' to the call make_from_constant() so I was wondering if it may change behavior. Specifically it may produce NULL now
>> if oop_constant->can_be_constant() is 'false':
>>
>>      if (require_constant) {
>>        if (!o->can_be_constant())  return NULL;
> 
> In the !JavaObjectInPerm world Strings should always return true for can_be_constant.  Actually I think it would be better to fix it by changing ciObject::should_be_constant instead of just patching that use. I also included Classes in the test for consistency with the old behaviour.  So I've removed the changes in parse3.cpp and done this instead.
> 
> diff -r 8e77e1f26188 src/share/vm/ci/ciObject.cpp                                                                                                     
> --- a/src/share/vm/ci/ciObject.cpp                                                                                                                   
> +++ b/src/share/vm/ci/ciObject.cpp                                                                                                                   
> @@ -194,6 +194,16 @@ bool ciObject::can_be_constant() {
>  // ciObject::should_be_constant()                                                                                                                   
>  bool ciObject::should_be_constant() {                                                                                                               
>    if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                                   
> +  if (!JavaObjectsInPerm) {                                                                                                                         
> +    // We want Strings and Classes to be embeddable by default since                                                                                 
> +    // they used to be in the perm world.  Not all Strings used to be                                                                               
> +    // embeddable but there's no easy way to distinguish the interned                                                                               
> +    // from the regulars ones so just treat them all that way.                                                                                       
> +    ciEnv* env = CURRENT_ENV;                                                                                                                       
> +    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                           
> +      return true;                                                                                                                                   
> +    }                                                                                                                                               
> +  }                                                                                                                                                 
>    return handle() == NULL || !is_scavengable();                                                                                                     
>  }
> 
> tom
> 
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> http://cr.openjdk.java.net/~never/7032162
>>> 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
>>> Reviewed-by:
>>> This appears to be an existing problem with OptimizeStringConcat where
>>> missing control can allow some loads to be split up to where their
>>> base is NULL which causes addresses that can't be analyzed.  The fix
>>> is to use the appropriate control.  If it's truly unneeded it will be
>>> optimized away.  The bug was exposed by the String not in perm changes
>>> because we were no longer treating some constant strings as embeddable
>>> constants.  This is fixed by handling them specially in push_constant.
>>> Tested with failing test from report and full CTW with string opts.
> 

From tom.rodriguez at oracle.com  Wed Apr  6 15:40:38 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 6 Apr 2011 15:40:38 -0700
Subject: review (S) for 7034513: enable fast accessors and empty methods for
	ZERO and -Xint
Message-ID: <DE638EB8-C9FC-43F1-9BC9-B4777C88E4E5@oracle.com>

http://cr.openjdk.java.net/~never/7034513

7034513: enable fast accessors and empty methods for ZERO and -Xint
Reviewed-by:

The fix for 6385687 unconditionally turned off
UseFastEmptyMethods/UseFastAccessorMethods but they should be on for
ZERO and -Xint mode.  It was easier to revert the defaults to on and
turn them off for when the compiler is being used.


From tom.rodriguez at oracle.com  Wed Apr  6 15:52:21 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 6 Apr 2011 15:52:21 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
In-Reply-To: <4D9CD5FC.4090202@oracle.com>
References: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
	<4D9CD1CB.6060108@oracle.com>
	<CC3EAA09-A1B8-4CB7-B1D4-02379BFFD1C6@oracle.com>
	<4D9CD5FC.4090202@oracle.com>
Message-ID: <D736CB6A-7DD6-45F4-9036-E40AB7C402B1@oracle.com>

Thanks!

tom

On Apr 6, 2011, at 2:07 PM, Vladimir Kozlov wrote:

> This looks better.
> 
> Thanks,
> Vladimir
> 
> Tom Rodriguez wrote:
>> On Apr 6, 2011, at 1:49 PM, Vladimir Kozlov wrote:
>>> You replaced 'require_constant' with 'true' to the call make_from_constant() so I was wondering if it may change behavior. Specifically it may produce NULL now
>>> if oop_constant->can_be_constant() is 'false':
>>> 
>>>     if (require_constant) {
>>>       if (!o->can_be_constant())  return NULL;
>> In the !JavaObjectInPerm world Strings should always return true for can_be_constant.  Actually I think it would be better to fix it by changing ciObject::should_be_constant instead of just patching that use. I also included Classes in the test for consistency with the old behaviour.  So I've removed the changes in parse3.cpp and done this instead.
>> diff -r 8e77e1f26188 src/share/vm/ci/ciObject.cpp                                                                                                     --- a/src/share/vm/ci/ciObject.cpp                                                                                                                   +++ b/src/share/vm/ci/ciObject.cpp                                                                                                                   @@ -194,6 +194,16 @@ bool ciObject::can_be_constant() {
>> // ciObject::should_be_constant()                                                                                                                    bool ciObject::should_be_constant() {                                                                                                                  if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                                   +  if (!JavaObjectsInPerm) {                                                                                                                         +    // We want Strings and Classes to be embeddable by default since                                                                                 +    // they used to be in the perm world.  Not all Strings used to be                                                                               +    // embeddable but there's no easy way to distinguish the interned                                                                               +    // from the regulars ones so just treat them all that way.                                                                                       +    ciEnv* env = CURRENT_ENV;                                                                                                                       +    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                           +      return true;                                                                                                                                   +    }                                                                                                                                               +  }                                                                                                                                                    return handle() == NULL || !is_scavengable();                                                                                                      }
>> tom
>>> Vladimir
>>> 
>>> Tom Rodriguez wrote:
>>>> http://cr.openjdk.java.net/~never/7032162
>>>> 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
>>>> Reviewed-by:
>>>> This appears to be an existing problem with OptimizeStringConcat where
>>>> missing control can allow some loads to be split up to where their
>>>> base is NULL which causes addresses that can't be analyzed.  The fix
>>>> is to use the appropriate control.  If it's truly unneeded it will be
>>>> optimized away.  The bug was exposed by the String not in perm changes
>>>> because we were no longer treating some constant strings as embeddable
>>>> constants.  This is fixed by handling them specially in push_constant.
>>>> Tested with failing test from report and full CTW with string opts.


From igor.veresov at oracle.com  Wed Apr  6 15:55:24 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 06 Apr 2011 15:55:24 -0700
Subject: review (S) for 7034513: enable fast accessors and empty methods
	for ZERO and -Xint
In-Reply-To: <DE638EB8-C9FC-43F1-9BC9-B4777C88E4E5@oracle.com>
References: <DE638EB8-C9FC-43F1-9BC9-B4777C88E4E5@oracle.com>
Message-ID: <4D9CEF5C.7030401@oracle.com>

Looks good.

igor

On 4/6/11 3:40 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7034513
>
> 7034513: enable fast accessors and empty methods for ZERO and -Xint
> Reviewed-by:
>
> The fix for 6385687 unconditionally turned off
> UseFastEmptyMethods/UseFastAccessorMethods but they should be on for
> ZERO and -Xint mode.  It was easier to revert the defaults to on and
> turn them off for when the compiler is being used.
>


From vladimir.kozlov at oracle.com  Wed Apr  6 16:41:48 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 06 Apr 2011 16:41:48 -0700
Subject: review (S) for 7034513: enable fast accessors and empty methods
	for ZERO and -Xint
In-Reply-To: <DE638EB8-C9FC-43F1-9BC9-B4777C88E4E5@oracle.com>
References: <DE638EB8-C9FC-43F1-9BC9-B4777C88E4E5@oracle.com>
Message-ID: <4D9CFA3C.8040209@oracle.com>

Please, put () around (mode == _int). Otherwise looks good.

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7034513
> 
> 7034513: enable fast accessors and empty methods for ZERO and -Xint
> Reviewed-by:
> 
> The fix for 6385687 unconditionally turned off
> UseFastEmptyMethods/UseFastAccessorMethods but they should be on for
> ZERO and -Xint mode.  It was easier to revert the defaults to on and
> turn them off for when the compiler is being used.
> 

From tom.rodriguez at oracle.com  Wed Apr  6 16:49:43 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 6 Apr 2011 16:49:43 -0700
Subject: review (S) for 7034513: enable fast accessors and empty methods
	for ZERO and -Xint
In-Reply-To: <4D9CFA3C.8040209@oracle.com>
References: <DE638EB8-C9FC-43F1-9BC9-B4777C88E4E5@oracle.com>
	<4D9CFA3C.8040209@oracle.com>
Message-ID: <2F9053CB-25D3-4EB3-9793-C58BA2F1F511@oracle.com>


On Apr 6, 2011, at 4:41 PM, Vladimir Kozlov wrote:

> Please, put () around (mode == _int). Otherwise looks good.

Ok.  Thanks Vladimir and Igor.

tom

> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7034513
>> 7034513: enable fast accessors and empty methods for ZERO and -Xint
>> Reviewed-by:
>> The fix for 6385687 unconditionally turned off
>> UseFastEmptyMethods/UseFastAccessorMethods but they should be on for
>> ZERO and -Xint mode.  It was easier to revert the defaults to on and
>> turn them off for when the compiler is being used.


From vladimir.kozlov at oracle.com  Wed Apr  6 16:58:31 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 06 Apr 2011 16:58:31 -0700
Subject: Request for reviews (XS): 6992789: assert(phi->_idx >= nodes_size())
	failed: only new Phi per instance memory slice
Message-ID: <4D9CFE27.6080903@oracle.com>

http://cr.openjdk.java.net/~kvn/6992789/webrev

Fixed 6992789: assert(phi->_idx >= nodes_size()) failed: only new Phi per 
instance memory slice

After instance's memory slices are split we update original phi inputs to skip 
stores to instance (Phase 4). We should keep original input if it was not memory 
node. In the bug case the input is an other Phi with different alias index and 
instead of keeping it the code tries to create new phi with original index. It 
happened because the check that it is not instance memory slice was done after 
compare indexes.

Swap checks: check for regular memory slice first and keep input phi.

From tom.rodriguez at oracle.com  Wed Apr  6 17:04:39 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 6 Apr 2011 17:04:39 -0700
Subject: Request for reviews (XS): 6992789: assert(phi->_idx >=
	nodes_size()) failed: only new Phi per instance memory slice
In-Reply-To: <4D9CFE27.6080903@oracle.com>
References: <4D9CFE27.6080903@oracle.com>
Message-ID: <2F0F0533-D3D7-446E-9640-ED8C95EAEBC4@oracle.com>

Looks good.

tom

On Apr 6, 2011, at 4:58 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/6992789/webrev
> 
> Fixed 6992789: assert(phi->_idx >= nodes_size()) failed: only new Phi per instance memory slice
> 
> After instance's memory slices are split we update original phi inputs to skip stores to instance (Phase 4). We should keep original input if it was not memory node. In the bug case the input is an other Phi with different alias index and instead of keeping it the code tries to create new phi with original index. It happened because the check that it is not instance memory slice was done after compare indexes.
> 
> Swap checks: check for regular memory slice first and keep input phi.


From tom.rodriguez at oracle.com  Wed Apr  6 19:12:18 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Thu, 07 Apr 2011 02:12:18 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7034513: enable fast accessors and
	empty methods for ZERO and -Xint
Message-ID: <20110407021220.91F7147866@hg.openjdk.java.net>

Changeset: 98c560260039
Author:    never
Date:      2011-04-06 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/98c560260039

7034513: enable fast accessors and empty methods for ZERO and -Xint
Reviewed-by: kvn, iveresov

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp


From vladimir.kozlov at oracle.com  Wed Apr  6 21:15:17 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Thu, 07 Apr 2011 04:15:17 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 6992789: assert(phi->_idx >=
	nodes_size()) failed: only new Phi per instance memory slice
Message-ID: <20110407041519.61B774786E@hg.openjdk.java.net>

Changeset: 55973726c600
Author:    kvn
Date:      2011-04-06 17:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/55973726c600

6992789: assert(phi->_idx >= nodes_size()) failed: only new Phi per instance memory slice
Summary: Swap checks: check for regular memory slice first and keep input phi.
Reviewed-by: never

! src/share/vm/opto/escape.cpp


From mark.g.j.christiaens at gmail.com  Thu Apr  7 06:25:56 2011
From: mark.g.j.christiaens at gmail.com (Mark Christiaens)
Date: Thu, 7 Apr 2011 15:25:56 +0200
Subject: How to provide feedback on hangs
Message-ID: <BANLkTikO8Om9Ron6JrJ7UnEV6wGgz2EO7A@mail.gmail.com>

Usually, I run my Eclipse IDE with the latest build of 1.7.  Sometimes, it
hangs solid.  I'd like to be able to provide some kind of bug report but the
only thing I can think of is doing an "strace ...".   When I do, I usually
see that the JVM is executing a futex.  But that's it.  Is there something I
can do or trigger to get more useful output so I can give a proper bug
report?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110407/180105e1/attachment.html 

From tom.rodriguez at oracle.com  Thu Apr  7 12:53:39 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 7 Apr 2011 12:53:39 -0700
Subject: review request (M): 7033154 Improve C1 arraycopy performance
In-Reply-To: <op.vs9nkdm6rz1tqb@grosvic>
References: <op.vs9nkdm6rz1tqb@grosvic>
Message-ID: <EF62B11A-9D61-4A4E-A1F1-54BDA6DE407A@oracle.com>

Just for the record I'd reviewed this privately.

tom

On Apr 1, 2011, at 8:49 AM, Roland Westrelin wrote:

> http://cr.openjdk.java.net/~roland/7033154/webrev.00/


From tom.rodriguez at oracle.com  Thu Apr  7 19:12:15 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 7 Apr 2011 19:12:15 -0700
Subject: review (XS) for 7034957: acquiring lock CodeCache_lock/1 out of order
	with lock tty_lock/0 -- possible deadlock
Message-ID: <B942A8D4-F071-46CC-8C7D-B51C602F16AD@oracle.com>

http://cr.openjdk.java.net/~never/7034957

7034957: acquiring lock CodeCache_lock/1 out of order with lock tty_lock/0 -- possible deadlock
Reviewed-by:

The code add in 7033779 to acquire the CodeCache_lock in
largest_free_block creates ordering problems with ttyLocker.  The
simplest thing is to add a ttyUnlocker.  Tested by running
-XX:+LogCompilation while triggering a sweep.


From igor.veresov at oracle.com  Thu Apr  7 19:28:27 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 07 Apr 2011 19:28:27 -0700
Subject: review (XS) for 7034957: acquiring lock CodeCache_lock/1 out
	of order with lock tty_lock/0 -- possible deadlock
In-Reply-To: <B942A8D4-F071-46CC-8C7D-B51C602F16AD@oracle.com>
References: <B942A8D4-F071-46CC-8C7D-B51C602F16AD@oracle.com>
Message-ID: <4D9E72CB.6020203@oracle.com>

Looks good.

igor

On 4/7/11 7:12 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7034957
>
> 7034957: acquiring lock CodeCache_lock/1 out of order with lock tty_lock/0 -- possible deadlock
> Reviewed-by:
>
> The code add in 7033779 to acquire the CodeCache_lock in
> largest_free_block creates ordering problems with ttyLocker.  The
> simplest thing is to add a ttyUnlocker.  Tested by running
> -XX:+LogCompilation while triggering a sweep.
>


From john.r.rose at oracle.com  Thu Apr  7 21:20:15 2011
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Fri, 08 Apr 2011 04:20:15 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 3 new changesets
Message-ID: <20110408042022.B20E1478C4@hg.openjdk.java.net>

Changeset: ed69575596ac
Author:    jrose
Date:      2011-04-07 17:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ed69575596ac

6981791: remove experimental code for JSR 292
Reviewed-by: twisti

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/constantTag.cpp
! src/share/vm/utilities/constantTag.hpp

Changeset: 758ba0bf7bcc
Author:    jrose
Date:      2011-04-07 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/758ba0bf7bcc

7012087: JSR 292 Misleading exception message for a non-bound MH for a virtual method
Summary: Improve error message formatting to give more information to user.  Also, catch a corner case related to 6930553 and 6844449.
Reviewed-by: kvn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 4124a5a27707
Author:    jrose
Date:      2011-04-07 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4124a5a27707

7009600: JSR 292 Server compiler crashes in Compile::find_intrinsic(ciMethod*, bool)
Summary: catch errors during the compile-time processing of method handles; back out cleanly
Reviewed-by: twisti

! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/opto/doCall.cpp


From john.r.rose at oracle.com  Thu Apr  7 21:43:01 2011
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 7 Apr 2011 21:43:01 -0700
Subject: review request (M): 6987991: JSR 292 phpreboot
	test/testtracefun2.phpr segfaults
Message-ID: <FC66FB8B-603B-414D-9A68-C3F765EE436F@oracle.com>

http://cr.openjdk.java.net/~jrose/6987991/webrev.01

6987991: JSR 292 phpreboot test/testtracefun2.phpr segfaults
Summary: Make MH verification tests more correct, robust, and informative.  Fix lingering symbol refcount problems.

-- John


From john.r.rose at oracle.com  Thu Apr  7 22:15:45 2011
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Fri, 08 Apr 2011 05:15:45 +0000
Subject: hg: jdk7/hotspot-comp/jdk: 6817525: turn on method handle
	functionality by default for JSR 292
Message-ID: <20110408051634.87F2F478C7@hg.openjdk.java.net>

Changeset: fa9c8e314f10
Author:    jrose
Date:      2011-04-07 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa9c8e314f10

6817525: turn on method handle functionality by default for JSR 292
Summary: JVM bug 6817525 requires changes to some JDK unit tests; update test invocation flags and "Indify" snapshot
Reviewed-by: kvn, twisti

! test/java/lang/invoke/6987555/Test6987555.java
! test/java/lang/invoke/6991596/Test6991596.java
! test/java/lang/invoke/InvokeDynamicPrintArgs.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/indify/Indify.java


From tom.rodriguez at oracle.com  Fri Apr  8 01:26:28 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Fri, 08 Apr 2011 08:26:28 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7034957: acquiring lock
	CodeCache_lock/1 out of order with lock tty_lock/0 -- possible
	deadlock
Message-ID: <20110408082631.93312478D7@hg.openjdk.java.net>

Changeset: 3f49d30f8184
Author:    never
Date:      2011-04-07 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f49d30f8184

7034957: acquiring lock CodeCache_lock/1 out of order with lock tty_lock/0 -- possible deadlock
Reviewed-by: iveresov

! src/share/vm/code/codeCache.cpp


From christian.thalinger at oracle.com  Fri Apr  8 02:50:10 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 8 Apr 2011 11:50:10 +0200
Subject: review request (M): 6987991: JSR 292 phpreboot
	test/testtracefun2.phpr segfaults
In-Reply-To: <FC66FB8B-603B-414D-9A68-C3F765EE436F@oracle.com>
References: <FC66FB8B-603B-414D-9A68-C3F765EE436F@oracle.com>
Message-ID: <DC19452A-90ED-408D-BFF3-64EDCEE964F1@oracle.com>

On Apr 8, 2011, at 6:43 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/6987991/webrev.01
> 
> 6987991: JSR 292 phpreboot test/testtracefun2.phpr segfaults
> Summary: Make MH verification tests more correct, robust, and informative.  Fix lingering symbol refcount problems.

Looks good.  -- Christian

From tom.rodriguez at oracle.com  Fri Apr  8 10:15:48 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 8 Apr 2011 10:15:48 -0700
Subject: Request for reviews (M): 7004555: Add new policy for one
	iteration loops
In-Reply-To: <4D9CBDD7.2040608@oracle.com>
References: <4D9CBDD7.2040608@oracle.com>
Message-ID: <D8551637-7D3B-453A-837C-622AD581541B@oracle.com>

loopTransform.cpp:

bounderies -> boundaries

There's a use UseNewCode left behind

loopnode.hpp:

The relationship between the loop_flags enum in LoopNode and the one in CountedLoopNode is kind of obscure.  Could you declare them together so it's more obvious?

Otherwise it looks good.

tom


On Apr 6, 2011, at 12:24 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/7004555/webrev
> 
> Fixed 7004555: Add new policy for one iteration loops
> 
> Add new policy for one iteration loops (mostly formal pre- loops) to fold exit condition and avoid going through do_maximally_unroll() as we do currently for such cases.
> Move exact trip count calculation from policy_maximally_unroll() into separate method. Note, trip_count type is changed to unsigned int and its range is changed to [0, max_juint). Add new flag HasExactTripCount to indicate that loop's limits and trip count are constants.
> Check for non overlaping init and limit values to avoid zero trip guard generation in remove_empty_loop.
> Rename some CountedLoopNode flags.
> Print loop iv range for counted loops dumps:
> 
> Loop: N286/N193  predicated counted [0,2),+1


From vladimir.kozlov at oracle.com  Fri Apr  8 10:41:39 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 08 Apr 2011 10:41:39 -0700
Subject: Request for reviews (M): 7004555: Add new policy for one iteration
	loops
In-Reply-To: <D8551637-7D3B-453A-837C-622AD581541B@oracle.com>
References: <4D9CBDD7.2040608@oracle.com>
	<D8551637-7D3B-453A-837C-622AD581541B@oracle.com>
Message-ID: <4D9F48D3.2010600@oracle.com>

Thank you, Tom

All fixed.
I moved flags to LoopNode class and renamed the rest of flags:

+  enum { Normal=0, Pre=1, Main=2, Post=3, PreMainPostFlagsMask=3,
+         MainHasNoPreLoop=4,
+         HasExactTripCount=8,
+         InnerLoop=16,
+         PartialPeelLoop=32,
+         PartialPeelFailed=64 };

-  enum { pre_post_main=0, inner_loop=8, partial_peel_loop=16, 
partial_peel_failed=32  };
-  enum { Normal=0, Pre=1, Main=2, Post=3, PrePostFlagsMask=3, 
Main_Has_No_Pre_Loop=4 };

Thanks,
Vladimir

Tom Rodriguez wrote:
> loopTransform.cpp:
> 
> bounderies -> boundaries
> 
> There's a use UseNewCode left behind
> 
> loopnode.hpp:
> 
> The relationship between the loop_flags enum in LoopNode and the one in CountedLoopNode is kind of obscure.  Could you declare them together so it's more obvious?
> 
> Otherwise it looks good.
> 
> tom
> 
> 
> On Apr 6, 2011, at 12:24 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/7004555/webrev
>>
>> Fixed 7004555: Add new policy for one iteration loops
>>
>> Add new policy for one iteration loops (mostly formal pre- loops) to fold exit condition and avoid going through do_maximally_unroll() as we do currently for such cases.
>> Move exact trip count calculation from policy_maximally_unroll() into separate method. Note, trip_count type is changed to unsigned int and its range is changed to [0, max_juint). Add new flag HasExactTripCount to indicate that loop's limits and trip count are constants.
>> Check for non overlaping init and limit values to avoid zero trip guard generation in remove_empty_loop.
>> Rename some CountedLoopNode flags.
>> Print loop iv range for counted loops dumps:
>>
>> Loop: N286/N193  predicated counted [0,2),+1
> 

From tom.rodriguez at oracle.com  Fri Apr  8 10:51:27 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 8 Apr 2011 10:51:27 -0700
Subject: Request for reviews (M): 7004555: Add new policy for one
	iteration loops
In-Reply-To: <4D9F48D3.2010600@oracle.com>
References: <4D9CBDD7.2040608@oracle.com>
	<D8551637-7D3B-453A-837C-622AD581541B@oracle.com>
	<4D9F48D3.2010600@oracle.com>
Message-ID: <22F8487B-F8C5-4A7B-A1AB-CE9E055FBD93@oracle.com>


On Apr 8, 2011, at 10:41 AM, Vladimir Kozlov wrote:

> Thank you, Tom
> 
> All fixed.
> I moved flags to LoopNode class and renamed the rest of flags:
> 
> +  enum { Normal=0, Pre=1, Main=2, Post=3, PreMainPostFlagsMask=3,
> +         MainHasNoPreLoop=4,
> +         HasExactTripCount=8,
> +         InnerLoop=16,
> +         PartialPeelLoop=32,
> +         PartialPeelFailed=64 };
> 
> -  enum { pre_post_main=0, inner_loop=8, partial_peel_loop=16, partial_peel_failed=32  };
> -  enum { Normal=0, Pre=1, Main=2, Post=3, PrePostFlagsMask=3, Main_Has_No_Pre_Loop=4 };

That's much better.  Thanks!

tom

> 
> Thanks,
> Vladimir
> 
> Tom Rodriguez wrote:
>> loopTransform.cpp:
>> bounderies -> boundaries
>> There's a use UseNewCode left behind
>> loopnode.hpp:
>> The relationship between the loop_flags enum in LoopNode and the one in CountedLoopNode is kind of obscure.  Could you declare them together so it's more obvious?
>> Otherwise it looks good.
>> tom
>> On Apr 6, 2011, at 12:24 PM, Vladimir Kozlov wrote:
>>> http://cr.openjdk.java.net/~kvn/7004555/webrev
>>> 
>>> Fixed 7004555: Add new policy for one iteration loops
>>> 
>>> Add new policy for one iteration loops (mostly formal pre- loops) to fold exit condition and avoid going through do_maximally_unroll() as we do currently for such cases.
>>> Move exact trip count calculation from policy_maximally_unroll() into separate method. Note, trip_count type is changed to unsigned int and its range is changed to [0, max_juint). Add new flag HasExactTripCount to indicate that loop's limits and trip count are constants.
>>> Check for non overlaping init and limit values to avoid zero trip guard generation in remove_empty_loop.
>>> Rename some CountedLoopNode flags.
>>> Print loop iv range for counted loops dumps:
>>> 
>>> Loop: N286/N193  predicated counted [0,2),+1


From john.cuthbertson at oracle.com  Fri Apr  8 11:04:19 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 08 Apr 2011 11:04:19 -0700
Subject: RFR(XS): 7035177: G1: nsk/stress/jni/jnistress002 fails with an
	assertion failure caused by changes for 7009266
Message-ID: <4D9F4E23.6060301@oracle.com>

Hi Everyone,

Can I have a couple of volunteers to look over the fix for this CR? The 
webrev can be found at: http://cr.openjdk.java.net/~johnc/7035177/webrev.0/.

The problem is that the node representing the offset (in an 
Unsafe.getObject compilation) could be typed as a long and generating 
the compare of offset against java_lang_ref_Reference::referent_offset 
(typed as an int) caused an assertion failure about the mis-matching types.

The fix is to generate a suitably typed constant based upon the type of 
"offset".

Tested using the failing test case from the nightly tests.

Thanks,

JohnC

From tom.rodriguez at oracle.com  Fri Apr  8 11:31:47 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 8 Apr 2011 11:31:47 -0700
Subject: RFR(XS): 7035177: G1: nsk/stress/jni/jnistress002 fails with an
	assertion failure caused by changes for 7009266
In-Reply-To: <4D9F4E23.6060301@oracle.com>
References: <4D9F4E23.6060301@oracle.com>
Message-ID: <5FAB74B1-C3A6-46C4-ABC3-E58380059D70@oracle.com>

Actually you want to write this:

  Node* referent_off = __ ConX(java_lang_ref_Reference::referent_offset);

which will pick ConL in 64 bit and ConI in 32 bit.  Sorry I didn't catch this in the review.

tom

On Apr 8, 2011, at 11:04 AM, John Cuthbertson wrote:

> Hi Everyone,
> 
> Can I have a couple of volunteers to look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7035177/webrev.0/.
> 
> The problem is that the node representing the offset (in an Unsafe.getObject compilation) could be typed as a long and generating the compare of offset against java_lang_ref_Reference::referent_offset (typed as an int) caused an assertion failure about the mis-matching types.
> 
> The fix is to generate a suitably typed constant based upon the type of "offset".
> 
> Tested using the failing test case from the nightly tests.
> 
> Thanks,
> 
> JohnC


From john.cuthbertson at oracle.com  Fri Apr  8 11:42:18 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 08 Apr 2011 11:42:18 -0700
Subject: RFR(XS): 7035177: G1: nsk/stress/jni/jnistress002 fails with
	an assertion failure caused by changes for 7009266
In-Reply-To: <5FAB74B1-C3A6-46C4-ABC3-E58380059D70@oracle.com>
References: <4D9F4E23.6060301@oracle.com>
	<5FAB74B1-C3A6-46C4-ABC3-E58380059D70@oracle.com>
Message-ID: <4D9F570A.60703@oracle.com>

Hi Tom,

Thanks. I'll make the change (which was what I started with and then 
changed it to it's current version).

JohnC

On 04/08/11 11:31, Tom Rodriguez wrote:
> Actually you want to write this:
>
>   Node* referent_off = __ ConX(java_lang_ref_Reference::referent_offset);
>
> which will pick ConL in 64 bit and ConI in 32 bit.  Sorry I didn't catch this in the review.
>
> tom
>
> On Apr 8, 2011, at 11:04 AM, John Cuthbertson wrote:
>
>   
>> Hi Everyone,
>>
>> Can I have a couple of volunteers to look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7035177/webrev.0/.
>>
>> The problem is that the node representing the offset (in an Unsafe.getObject compilation) could be typed as a long and generating the compare of offset against java_lang_ref_Reference::referent_offset (typed as an int) caused an assertion failure about the mis-matching types.
>>
>> The fix is to generate a suitably typed constant based upon the type of "offset".
>>
>> Tested using the failing test case from the nightly tests.
>>
>> Thanks,
>>
>> JohnC
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110408/49a61400/attachment.html 

From tom.rodriguez at oracle.com  Fri Apr  8 14:30:06 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 8 Apr 2011 14:30:06 -0700
Subject: review for 7035161: assert(!o->is_null_object()) failed: null object
	not yet handled here.
Message-ID: <42AB04C5-6435-4559-A31D-A7C0146D7608@oracle.com>

http://cr.openjdk.java.net/~never/7035161

7035161: assert(!o->is_null_object()) failed: null object not yet handled here.
Reviewed-by:

There's a bare oop across the call to ciField::type which might cause
a safepoint resulting in the field being read from a stale oop.
Tested with crashing test nsk.stress.jck12a.jck12a006.jck12a006.


From vladimir.kozlov at oracle.com  Fri Apr  8 14:51:41 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 08 Apr 2011 14:51:41 -0700
Subject: review for 7035161: assert(!o->is_null_object()) failed: null
	object not yet handled here.
In-Reply-To: <42AB04C5-6435-4559-A31D-A7C0146D7608@oracle.com>
References: <42AB04C5-6435-4559-A31D-A7C0146D7608@oracle.com>
Message-ID: <4D9F836D.5030704@oracle.com>

Can we just move it after type() call?:

   71   BasicType field_btype = field->type()->basic_type();
   72   int offset = field->offset();
   69   oop obj = get_oop();
   70   assert(obj != NULL, "bad oop");

I agree that using handle is much safer and I am fine if you want to push code 
with handle.

Thanks,
Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7035161
> 
> 7035161: assert(!o->is_null_object()) failed: null object not yet handled here.
> Reviewed-by:
> 
> There's a bare oop across the call to ciField::type which might cause
> a safepoint resulting in the field being read from a stale oop.
> Tested with crashing test nsk.stress.jck12a.jck12a006.jck12a006.
> 

From tom.rodriguez at oracle.com  Fri Apr  8 15:01:28 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 8 Apr 2011 15:01:28 -0700
Subject: review for 7035161: assert(!o->is_null_object()) failed: null
	object not yet handled here.
In-Reply-To: <4D9F836D.5030704@oracle.com>
References: <42AB04C5-6435-4559-A31D-A7C0146D7608@oracle.com>
	<4D9F836D.5030704@oracle.com>
Message-ID: <E5D6C9AD-118A-4CF3-B035-9C8C7FE1C7B8@oracle.com>


On Apr 8, 2011, at 2:51 PM, Vladimir Kozlov wrote:

> Can we just move it after type() call?:

I started to do that but we really should be using Handles for safety so I made that change instead.  It's a long enough piece of code that I think a handle is warranted.  Thanks!

tom

> 
>  71   BasicType field_btype = field->type()->basic_type();
>  72   int offset = field->offset();
>  69   oop obj = get_oop();
>  70   assert(obj != NULL, "bad oop");
> 
> I agree that using handle is much safer and I am fine if you want to push code with handle.
> 
> Thanks,
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7035161
>> 7035161: assert(!o->is_null_object()) failed: null object not yet handled here.
>> Reviewed-by:
>> There's a bare oop across the call to ciField::type which might cause
>> a safepoint resulting in the field being read from a stale oop.
>> Tested with crashing test nsk.stress.jck12a.jck12a006.jck12a006.


From vladimir.kozlov at oracle.com  Fri Apr  8 15:01:58 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 08 Apr 2011 15:01:58 -0700
Subject: review for 7035161: assert(!o->is_null_object()) failed: null
	object not yet handled here.
In-Reply-To: <E5D6C9AD-118A-4CF3-B035-9C8C7FE1C7B8@oracle.com>
References: <42AB04C5-6435-4559-A31D-A7C0146D7608@oracle.com>
	<4D9F836D.5030704@oracle.com>
	<E5D6C9AD-118A-4CF3-B035-9C8C7FE1C7B8@oracle.com>
Message-ID: <4D9F85D6.40902@oracle.com>

Tom Rodriguez wrote:
> On Apr 8, 2011, at 2:51 PM, Vladimir Kozlov wrote:
> 
>> Can we just move it after type() call?:
> 
> I started to do that but we really should be using Handles for safety so I made that change instead.  It's a long enough piece of code that I think a handle is warranted.  Thanks!

OK.

Vladimir

> 
> tom
> 
>>  71   BasicType field_btype = field->type()->basic_type();
>>  72   int offset = field->offset();
>>  69   oop obj = get_oop();
>>  70   assert(obj != NULL, "bad oop");
>>
>> I agree that using handle is much safer and I am fine if you want to push code with handle.
>>
>> Thanks,
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> http://cr.openjdk.java.net/~never/7035161
>>> 7035161: assert(!o->is_null_object()) failed: null object not yet handled here.
>>> Reviewed-by:
>>> There's a bare oop across the call to ciField::type which might cause
>>> a safepoint resulting in the field being read from a stale oop.
>>> Tested with crashing test nsk.stress.jck12a.jck12a006.jck12a006.
> 

From igor.veresov at oracle.com  Fri Apr  8 15:47:23 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 08 Apr 2011 15:47:23 -0700
Subject: review(M): 7034967: C1: assert(false) failed: error
	(assembler_sparc.cpp:2043)
Message-ID: <4D9F907B.9050704@oracle.com>

The assert is a verification failure originated from 
LIR_Assembler::emit_unwind_handler() complaining that the exception oop 
is null. The verification code was invalid, because in 
C1_MacroAssembler::verify_not_null_oop() we used br_zero() to check for 
null, which actually checks only the least significant 32bits. Now 
br_notnull is used instead.

Also, I found that VerifyOops didn't work with 64bit C1 (both x64 and 
sparc), which is also fixed.


Webrev: http://cr.openjdk.java.net/~iveresov/7034967/webrev.00/


Thanks,
igor

From vladimir.kozlov at oracle.com  Fri Apr  8 15:57:43 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 08 Apr 2011 15:57:43 -0700
Subject: review(M): 7034967: C1: assert(false) failed: error
	(assembler_sparc.cpp:2043)
In-Reply-To: <4D9F907B.9050704@oracle.com>
References: <4D9F907B.9050704@oracle.com>
Message-ID: <4D9F92E7.4070509@oracle.com>

Looks good.

c1_CodeStubs_x86.cpp: add explanation (as you explained me) why small code is 
needed here:
+     // Load without verification to keep code size small. Also, we know it's 
not null.

c1_LIRGenerator.cpp:
+     // ptr cannot cannot be an object because we use this barrier for array
                     ^ repeated

Vladimir

Igor Veresov wrote:
> The assert is a verification failure originated from 
> LIR_Assembler::emit_unwind_handler() complaining that the exception oop 
> is null. The verification code was invalid, because in 
> C1_MacroAssembler::verify_not_null_oop() we used br_zero() to check for 
> null, which actually checks only the least significant 32bits. Now 
> br_notnull is used instead.
> 
> Also, I found that VerifyOops didn't work with 64bit C1 (both x64 and 
> sparc), which is also fixed.
> 
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/7034967/webrev.00/
> 
> 
> Thanks,
> igor

From igor.veresov at oracle.com  Fri Apr  8 16:07:54 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 08 Apr 2011 16:07:54 -0700
Subject: review(M): 7034967: C1: assert(false) failed: error
	(assembler_sparc.cpp:2043)
In-Reply-To: <4D9F92E7.4070509@oracle.com>
References: <4D9F907B.9050704@oracle.com> <4D9F92E7.4070509@oracle.com>
Message-ID: <4D9F954A.6030607@oracle.com>

Thanks!

Webrev updated.

igor

On 4/8/11 3:57 PM, Vladimir Kozlov wrote:
> Looks good.
>
> c1_CodeStubs_x86.cpp: add explanation (as you explained me) why small
> code is needed here:
> + // Load without verification to keep code size small. Also, we know
> it's not null.
>
> c1_LIRGenerator.cpp:
> + // ptr cannot cannot be an object because we use this barrier for array
> ^ repeated
>
> Vladimir
>
> Igor Veresov wrote:
>> The assert is a verification failure originated from
>> LIR_Assembler::emit_unwind_handler() complaining that the exception
>> oop is null. The verification code was invalid, because in
>> C1_MacroAssembler::verify_not_null_oop() we used br_zero() to check
>> for null, which actually checks only the least significant 32bits. Now
>> br_notnull is used instead.
>>
>> Also, I found that VerifyOops didn't work with 64bit C1 (both x64 and
>> sparc), which is also fixed.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/7034967/webrev.00/
>>
>>
>> Thanks,
>> igor


From vladimir.kozlov at oracle.com  Fri Apr  8 16:10:19 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 08 Apr 2011 16:10:19 -0700
Subject: review(M): 7034967: C1: assert(false) failed: error
	(assembler_sparc.cpp:2043)
In-Reply-To: <4D9F954A.6030607@oracle.com>
References: <4D9F907B.9050704@oracle.com> <4D9F92E7.4070509@oracle.com>
	<4D9F954A.6030607@oracle.com>
Message-ID: <4D9F95DB.8070400@oracle.com>

Looks good.

Vladimir

Igor Veresov wrote:
> Thanks!
> 
> Webrev updated.
> 
> igor
> 
> On 4/8/11 3:57 PM, Vladimir Kozlov wrote:
>> Looks good.
>>
>> c1_CodeStubs_x86.cpp: add explanation (as you explained me) why small
>> code is needed here:
>> + // Load without verification to keep code size small. Also, we know
>> it's not null.
>>
>> c1_LIRGenerator.cpp:
>> + // ptr cannot cannot be an object because we use this barrier for array
>> ^ repeated
>>
>> Vladimir
>>
>> Igor Veresov wrote:
>>> The assert is a verification failure originated from
>>> LIR_Assembler::emit_unwind_handler() complaining that the exception
>>> oop is null. The verification code was invalid, because in
>>> C1_MacroAssembler::verify_not_null_oop() we used br_zero() to check
>>> for null, which actually checks only the least significant 32bits. Now
>>> br_notnull is used instead.
>>>
>>> Also, I found that VerifyOops didn't work with 64bit C1 (both x64 and
>>> sparc), which is also fixed.
>>>
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/7034967/webrev.00/
>>>
>>>
>>> Thanks,
>>> igor
> 

From tom.rodriguez at oracle.com  Fri Apr  8 16:17:25 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 8 Apr 2011 16:17:25 -0700
Subject: review(M): 7034967: C1: assert(false) failed: error
	(assembler_sparc.cpp:2043)
In-Reply-To: <4D9F907B.9050704@oracle.com>
References: <4D9F907B.9050704@oracle.com>
Message-ID: <623E48F4-3340-4C41-AF13-A07195281959@oracle.com>

Looks good.

tom

On Apr 8, 2011, at 3:47 PM, Igor Veresov wrote:

> The assert is a verification failure originated from LIR_Assembler::emit_unwind_handler() complaining that the exception oop is null. The verification code was invalid, because in C1_MacroAssembler::verify_not_null_oop() we used br_zero() to check for null, which actually checks only the least significant 32bits. Now br_notnull is used instead.
> 
> Also, I found that VerifyOops didn't work with 64bit C1 (both x64 and sparc), which is also fixed.
> 
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/7034967/webrev.00/
> 
> 
> Thanks,
> igor


From igor.veresov at oracle.com  Fri Apr  8 16:40:27 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 08 Apr 2011 16:40:27 -0700
Subject: review(M): 7034967: C1: assert(false) failed: error
	(assembler_sparc.cpp:2043)
In-Reply-To: <623E48F4-3340-4C41-AF13-A07195281959@oracle.com>
References: <4D9F907B.9050704@oracle.com>
	<623E48F4-3340-4C41-AF13-A07195281959@oracle.com>
Message-ID: <4D9F9CEB.4020902@oracle.com>

Thanks Vladimir and Tom!

igor

On 4/8/11 4:17 PM, Tom Rodriguez wrote:
> Looks good.
>
> tom
>
> On Apr 8, 2011, at 3:47 PM, Igor Veresov wrote:
>
>> The assert is a verification failure originated from LIR_Assembler::emit_unwind_handler() complaining that the exception oop is null. The verification code was invalid, because in C1_MacroAssembler::verify_not_null_oop() we used br_zero() to check for null, which actually checks only the least significant 32bits. Now br_notnull is used instead.
>>
>> Also, I found that VerifyOops didn't work with 64bit C1 (both x64 and sparc), which is also fixed.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/7034967/webrev.00/
>>
>>
>> Thanks,
>> igor
>


From igor.veresov at oracle.com  Fri Apr  8 20:48:51 2011
From: igor.veresov at oracle.com (igor.veresov at oracle.com)
Date: Sat, 09 Apr 2011 03:48:51 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7034967: C1: assert(false) failed:
	error (assembler_sparc.cpp:2043)
Message-ID: <20110409034856.0906247911@hg.openjdk.java.net>

Changeset: d86923d96dca
Author:    iveresov
Date:      2011-04-08 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d86923d96dca

7034967: C1: assert(false) failed: error (assembler_sparc.cpp:2043)
Summary: Fix -XX:+VerifyOops
Reviewed-by: kvn, never

! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp


From vladimir.kozlov at oracle.com  Fri Apr  8 22:51:30 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 09 Apr 2011 05:51:30 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20110409055135.BCAE847917@hg.openjdk.java.net>

Changeset: 3af54845df98
Author:    kvn
Date:      2011-04-08 14:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3af54845df98

7004555: Add new policy for one iteration loops
Summary: Add new policy for one iteration loops (mostly formal pre- loops).
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp

Changeset: 46d145ee8e68
Author:    kvn
Date:      2011-04-08 20:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/46d145ee8e68

Merge



From tom.rodriguez at oracle.com  Sat Apr  9 02:57:18 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Sat, 09 Apr 2011 09:57:18 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7035161: assert(!o->is_null_object())
	failed: null object not yet handled here.
Message-ID: <20110409095724.A928347920@hg.openjdk.java.net>

Changeset: 3fa3c7e4d4f3
Author:    never
Date:      2011-04-08 23:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3fa3c7e4d4f3

7035161: assert(!o->is_null_object()) failed: null object not yet handled here.
Reviewed-by: kvn

! src/share/vm/ci/ciInstance.cpp


From john.r.rose at oracle.com  Sat Apr  9 21:13:47 2011
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 9 Apr 2011 21:13:47 -0700
Subject: review request (M): 6987991: JSR 292 phpreboot
	test/testtracefun2.phpr segfaults
In-Reply-To: <DC19452A-90ED-408D-BFF3-64EDCEE964F1@oracle.com>
References: <FC66FB8B-603B-414D-9A68-C3F765EE436F@oracle.com>
	<DC19452A-90ED-408D-BFF3-64EDCEE964F1@oracle.com>
Message-ID: <A6859E9C-0BE8-4BD2-BBEC-7F44CB43A331@oracle.com>

Thanks, Christian.  -- John

On Apr 8, 2011, at 2:50 AM, Christian Thalinger wrote:

> On Apr 8, 2011, at 6:43 AM, John Rose wrote:
>> http://cr.openjdk.java.net/~jrose/6987991/webrev.01
>> 
>> 6987991: JSR 292 phpreboot test/testtracefun2.phpr segfaults
>> Summary: Make MH verification tests more correct, robust, and informative.  Fix lingering symbol refcount problems.
> 
> Looks good.  -- Christian


From john.r.rose at oracle.com  Sat Apr  9 21:39:36 2011
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Sun, 10 Apr 2011 04:39:36 +0000
Subject: hg: jdk7/hotspot-comp/jdk: 7019529: JSR292:
	java/dyn/ClassValueTest.java depends on sub-test execution order
Message-ID: <20110410044027.2FC874794F@hg.openjdk.java.net>

Changeset: fb1d421c1e97
Author:    jrose
Date:      2011-04-09 21:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fb1d421c1e97

7019529: JSR292: java/dyn/ClassValueTest.java depends on sub-test execution order
Summary: Test should not use static variables, because they may contain stale values.
Reviewed-by: twisti

! test/java/lang/invoke/ClassValueTest.java


From john.r.rose at oracle.com  Sat Apr  9 23:30:41 2011
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Sun, 10 Apr 2011 06:30:41 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 28 new changesets
Message-ID: <20110410063130.D7E0947958@hg.openjdk.java.net>

Changeset: 7449da4cdab5
Author:    schien
Date:      2011-03-24 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7449da4cdab5

Added tag jdk7-b135 for changeset b898f0fc3ced

! .hgtags

Changeset: 661c46a8434c
Author:    trims
Date:      2011-03-25 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/661c46a8434c

Added tag hs21-b05 for changeset b898f0fc3ced

! .hgtags

Changeset: c10b82a05d58
Author:    trims
Date:      2011-03-25 18:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c10b82a05d58

Merge

- test/compiler/6987555/Test6987555.java
- test/compiler/6991596/Test6991596.java

Changeset: bd586e392d93
Author:    trims
Date:      2011-03-25 18:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bd586e392d93

7031227: Bump the HS21 build number to 06
Summary: Update the HS21 build number to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 74e790c48cd4
Author:    sla
Date:      2011-03-28 12:48 +0200
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/74e790c48cd4

7031571: Generate native VS2010 project files
Reviewed-by: hosterda, stefank, brutisso

! make/windows/create.bat
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/rules.make
! src/share/tools/ProjectCreator/Util.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
+ src/share/tools/ProjectCreator/WinGammaPlatformVC10.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java

Changeset: df553e4a797b
Author:    acorn
Date:      2011-03-30 17:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/df553e4a797b

Merge


Changeset: 6b9eb6d07c62
Author:    kvn
Date:      2011-04-01 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6b9eb6d07c62

Merge


Changeset: a1615ff22854
Author:    schien
Date:      2011-03-31 18:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a1615ff22854

Added tag jdk7-b136 for changeset bd586e392d93

! .hgtags

Changeset: 2ffcf94550d5
Author:    trims
Date:      2011-04-01 12:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2ffcf94550d5

Added tag hs21-b06 for changeset bd586e392d93

! .hgtags

Changeset: 7ea7c9c0305c
Author:    trims
Date:      2011-04-01 20:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7ea7c9c0305c

Merge


Changeset: 2dbcb4a4d8da
Author:    trims
Date:      2011-04-01 20:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2dbcb4a4d8da

7033237: Bump the HS21 build number to 07
Summary: Update the HS21 build number to 07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1d1603768966
Author:    trims
Date:      2011-04-05 14:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1d1603768966

7010070: Update all 2010 Oracle-changed OpenJDK files to have the proper copyright dates - second pass
Summary: Update the copyright to be 2010 on all changed files in OpenJDK
Reviewed-by: ohair

! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java
! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java
! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java
! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java
! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java
! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/types/Field.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java
! make/linux/Makefile
! make/linux/makefiles/arm.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/linux/makefiles/ppc.make
! make/linux/makefiles/sparcWorks.make
! make/linux/makefiles/top.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/adlc.make
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/rules.make
! make/solaris/makefiles/top.make
! make/solaris/makefiles/vm.make
! make/windows/create_obj_files.sh
! make/windows/makefiles/launcher.make
! make/windows/makefiles/vm.make
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/dump_sparc.cpp
! src/cpu/sparc/vm/jni_sparc.h
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/x86/vm/jni_x86.h
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/zero/vm/jni_zero.h
! src/os/linux/vm/jvm_linux.cpp
! src/os/linux/vm/osThread_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/linux/vm/thread_linux.inline.hpp
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/os/solaris/dtrace/libjvm_db.c
! src/os/solaris/vm/dtraceJSDT_solaris.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/share/tools/hsdis/hsdis-demo.c
! src/share/tools/hsdis/hsdis.c
! src/share/vm/adlc/main.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Defs.hpp
! src/share/vm/c1/c1_FpuStackSim.hpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_LinearScan.hpp
! src/share/vm/c1/c1_MacroAssembler.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/ci/ciClassList.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciKlass.cpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciObject.hpp
! src/share/vm/ci/ciObjectFactory.hpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciSymbol.cpp
! src/share/vm/ci/ciSymbol.hpp
! src/share/vm/ci/compilerInterface.hpp
! src/share/vm/classfile/classFileError.cpp
! src/share/vm/classfile/classFileStream.hpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/dictionary.hpp
! src/share/vm/classfile/javaAssertions.cpp
! src/share/vm/classfile/loaderConstraints.cpp
! src/share/vm/classfile/loaderConstraints.hpp
! src/share/vm/classfile/placeholders.cpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/classfile/resolutionErrors.cpp
! src/share/vm/classfile/resolutionErrors.hpp
! src/share/vm/classfile/stackMapFrame.cpp
! src/share/vm/classfile/stackMapFrame.hpp
! src/share/vm/classfile/stackMapTable.cpp
! src/share/vm/classfile/stackMapTable.hpp
! src/share/vm/classfile/verificationType.cpp
! src/share/vm/classfile/verificationType.hpp
! src/share/vm/classfile/verifier.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/compiledIC.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/icBuffer.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/code/vmreg.hpp
! src/share/vm/compiler/compileLog.hpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
! src/share/vm/gc_implementation/shared/gcUtil.cpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp
! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp
! src/share/vm/interpreter/cppInterpreter.hpp
! src/share/vm/interpreter/cppInterpreterGenerator.hpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/interpreter/interpreterGenerator.hpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/interpreter/templateTable.hpp
! src/share/vm/memory/barrierSet.cpp
! src/share/vm/memory/classify.cpp
! src/share/vm/memory/compactingPermGenGen.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/memory/restore.cpp
! src/share/vm/memory/serialize.cpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayOop.cpp
! src/share/vm/oops/cpCacheKlass.hpp
! src/share/vm/oops/generateOopMap.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/markOop.hpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/oops/typeArrayOop.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/output.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/regmask.cpp
! src/share/vm/opto/regmask.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/precompiled.hpp
! src/share/vm/prims/forte.cpp
! src/share/vm/prims/jni_md.h
! src/share/vm/prims/jvm_misc.hpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.hpp
! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/dtraceJSDT.hpp
! src/share/vm/runtime/fieldDescriptor.hpp
! src/share/vm/runtime/fieldType.cpp
! src/share/vm/runtime/fieldType.hpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/frame.inline.hpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/icache.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/javaCalls.hpp
! src/share/vm/runtime/javaFrameAnchor.hpp
! src/share/vm/runtime/jniHandles.cpp
! src/share/vm/runtime/objectMonitor.cpp
! src/share/vm/runtime/reflection.hpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/registerMap.hpp
! src/share/vm/runtime/rframe.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/signature.hpp
! src/share/vm/runtime/stackValueCollection.cpp
! src/share/vm/runtime/statSampler.cpp
! src/share/vm/runtime/stubCodeGenerator.cpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/threadLocalStorage.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vmStructs.hpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/shark/sharkNativeWrapper.cpp
! src/share/vm/utilities/copy.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/elfSymbolTable.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp
! src/share/vm/utilities/globalDefinitions_visCPP.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp
! src/share/vm/utilities/hashtable.inline.hpp
! src/share/vm/utilities/ostream.hpp
! src/share/vm/utilities/taskqueue.hpp
! src/share/vm/utilities/utf8.cpp
! src/share/vm/utilities/utf8.hpp
! src/share/vm/utilities/xmlstream.cpp
! src/share/vm/utilities/xmlstream.hpp

Changeset: a0de1dfd1933
Author:    ysr
Date:      2011-03-24 15:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a0de1dfd1933

7030435: Some oop_oop_iterate_m() methods iterate outside of specified memory bounds
Summary: Filter ref-containing locations through the memory-interval specified in the call.
Reviewed-by: jcoomes, jwilhelm, tonyp

! src/share/vm/oops/constantPoolKlass.cpp

Changeset: 5134fa1cfe63
Author:    ysr
Date:      2011-03-24 15:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5134fa1cfe63

7029036: Card-table verification hangs with all framework collectors, except G1, even before the first GC
Summary: When verifying clean card ranges, use memory-range-bounded iteration over oops of objects overlapping that range, thus avoiding the otherwise quadratic worst-case cost of scanning large object arrays.
Reviewed-by: jmasa, jwilhelm, tonyp

! src/share/vm/memory/cardTableRS.cpp

Changeset: c6580380076b
Author:    jcoomes
Date:      2011-03-25 17:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c6580380076b

Merge


Changeset: 5c0b591e1074
Author:    brutisso
Date:      2011-03-23 14:12 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5c0b591e1074

6948149: G1: Imbalance in termination times
Summary: Changed default value of WorkStealingYieldsBeforeSleep from 1000 to 5000. Added more information to G1 pause logging.
Reviewed-by: jwilhelm, tonyp, jmasa

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 02f49b66361a
Author:    johnc
Date:      2011-03-28 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/02f49b66361a

7026932: G1: No need to abort VM when card count cache expansion fails
Summary: Manage allocation/freeing of the card cache counts and epochs arrays directly so that an allocation failure while attempting to expand these arrays does not abort the JVM. Failure to expand these arrays is not fatal.
Reviewed-by: iveresov, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 455328d90876
Author:    tonyp
Date:      2011-03-29 22:36 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/455328d90876

7029458: G1: Add newly-reclaimed regions to the beginning of the region free list, not the end
Summary: What the synopsis says.
Reviewed-by: jwilhelm, iveresov, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegionSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp

Changeset: abdfc822206f
Author:    tonyp
Date:      2011-03-30 10:26 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/abdfc822206f

7023069: G1: Introduce symmetric locking in the slow allocation path
7023151: G1: refactor the code that operates on _cur_alloc_region to be re-used for allocs by the GC threads
7018286: G1: humongous allocation attempts should take the GC locker into account
Summary: First, this change replaces the asymmetric locking scheme in the G1 slow alloc path by a summetric one. Second, it factors out the code that operates on _cur_alloc_region so that it can be re-used for allocations by the GC threads in the future.
Reviewed-by: stefank, brutisso, johnc

+ src/share/vm/gc_implementation/g1/g1AllocRegion.cpp
+ src/share/vm/gc_implementation/g1/g1AllocRegion.hpp
+ src/share/vm/gc_implementation/g1/g1AllocRegion.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/space.cpp

Changeset: c84ee870e0b9
Author:    tonyp
Date:      2011-04-04 13:18 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c84ee870e0b9

7033292: G1: nightly failure: Non-dirty cards in region that should be dirty
Summary: The epochs on the card cache array are initialized to 0 and our initial epoch also starts at 0. So, until the first GC, it might be possible to successfully "claim" a card which was in fact never initialized.
Reviewed-by: johnc, iveresov, ysr

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp

Changeset: 371bbc844bf1
Author:    tonyp
Date:      2011-04-04 14:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/371bbc844bf1

7027766: G1: introduce flag to dump the liveness information per region at the end of marking
Summary: Repurpose the existing flag G1PrintRegionLivenessInfo to print out the liveness distribution across the regions in the heap at the end of marking.
Reviewed-by: iveresov, jwilhelm

! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp

Changeset: 8f1042ff784d
Author:    johnc
Date:      2011-02-18 10:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8f1042ff784d

7020042: G1: Partially remove fix for 6994628
Summary: Disable reference discovery and processing during concurrent marking by disabling fix for 6994628.
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 4f978fb6c81a
Author:    jmasa
Date:      2011-04-06 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f978fb6c81a

Merge

! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 9e6733fb56f8
Author:    schien
Date:      2011-04-07 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9e6733fb56f8

Added tag jdk7-b137 for changeset 2dbcb4a4d8da

! .hgtags

Changeset: 987d9d10a30a
Author:    trims
Date:      2011-04-08 15:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/987d9d10a30a

Added tag hs21-b07 for changeset 2dbcb4a4d8da

! .hgtags

Changeset: 24fbb4b7c2d3
Author:    trims
Date:      2011-04-08 16:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/24fbb4b7c2d3

Merge


Changeset: 0930dc920c18
Author:    trims
Date:      2011-04-08 16:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0930dc920c18

7035259: Bump the HS21 build number to 08
Summary: Update the HS21 build number to 08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 6c97c830fb6f
Author:    jrose
Date:      2011-04-09 21:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c97c830fb6f

Merge

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp


From john.r.rose at oracle.com  Sun Apr 10 04:12:00 2011
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Sun, 10 Apr 2011 11:12:00 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 6987991: JSR 292 phpreboot
	test/testtracefun2.phpr segfaults
Message-ID: <20110410111205.05B6D47963@hg.openjdk.java.net>

Changeset: 328926869b15
Author:    jrose
Date:      2011-04-09 22:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/328926869b15

6987991: JSR 292 phpreboot test/testtracefun2.phpr segfaults
Summary: Make MH verification tests more correct, robust, and informative.  Fix lingering symbol refcount problems.
Reviewed-by: twisti

! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp


From christian.thalinger at oracle.com  Mon Apr 11 05:45:56 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 11 Apr 2011 14:45:56 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110405134616.GA3243@redhat.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
	<D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
	<20110405134616.GA3243@redhat.com>
Message-ID: <E77F1601-18AB-4275-8504-4057C957E5C7@oracle.com>

On Apr 5, 2011, at 3:46 PM, Gary Benson wrote:
> Christian Thalinger wrote:
>> On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
>>> John Rose wrote:
>>>> On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
>>>>> This webrev adds support for JSR 292 to Zero:
>>>>> 
>>>>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
>>>> 
>>>> Most impressive!  I think this matches the following previously
>>>> filed bug:
>>>> 
>>>> 6829195  JSR 292 needs to support the C++ interpreter
>>> 
>>> Partially, yes, in that it implements invokedynamic and fast_aldc*
>>> in the bytecode interpreter.  For the sparc or x86 ports you would
>>> also need to write the method handle entries and add frame manager
>>> support for the call_method_handle message.
>> 
>> How much work would that be?
> 
> I'm not sure.  Actually, thinking about it, the method handle entries
> are already there (the template and C++ interpreters have the same
> ABI, no?)  You could check by trying to run the method handles tests.
> If that's the case, the only extra bit is adding support for
> call_method_handle.  There's a potential trap, however, in that the
> calls to InterpreterRuntime::resolve_invokedynamic and
> InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run enter VM
> mode and end up reentering the C++ interpreter.  I don't know that the
> assembly language ports can handle this.  They're certainly written to
> avoid it, but that might be simply because BytecodeInterpreter::run
> has a huge stack frame and they didn't want too many of those on the
> stack.  If it is a problem I have some partially written code that
> would work around this but once I realised Zero didn't need it I
> stopped working on it.

I'm not exactly sure how to proceed here.  Should we try to implement the missing parts of 6829195 or should we file a separate bug for Zero and push this?

-- Christian

From gbenson at redhat.com  Mon Apr 11 06:16:40 2011
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 11 Apr 2011 14:16:40 +0100
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <E77F1601-18AB-4275-8504-4057C957E5C7@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
	<D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
	<20110405134616.GA3243@redhat.com>
	<E77F1601-18AB-4275-8504-4057C957E5C7@oracle.com>
Message-ID: <20110411131640.GA8649@redhat.com>

Christian Thalinger wrote:
> On Apr 5, 2011, at 3:46 PM, Gary Benson wrote:
> > Christian Thalinger wrote:
> > > On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
> > > > John Rose wrote:
> > > > > On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
> > > > > > This webrev adds support for JSR 292 to Zero:
> > > > > > 
> > > > > > http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
> > > > > 
> > > > > Most impressive!  I think this matches the following
> > > > > previously filed bug:
> > > > > 
> > > > > 6829195  JSR 292 needs to support the C++ interpreter
> > > > 
> > > > Partially, yes, in that it implements invokedynamic and
> > > > fast_aldc* in the bytecode interpreter.  For the sparc or x86
> > > > ports you would also need to write the method handle entries
> > > > and add frame manager support for the call_method_handle
> > > > message.
> > > 
> > > How much work would that be?
> > 
> > I'm not sure.  Actually, thinking about it, the method handle
> > entries are already there (the template and C++ interpreters have
> > the same ABI, no?)  You could check by trying to run the method
> > handles tests.  If that's the case, the only extra bit is adding
> > support for call_method_handle.  There's a potential trap,
> > however, in that the calls to
> > InterpreterRuntime::resolve_invokedynamic and
> > InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run
> > enter VM mode and end up reentering the C++ interpreter.  I don't
> > know that the assembly language ports can handle this.  They're
> > certainly written to avoid it, but that might be simply because
> > BytecodeInterpreter::run has a huge stack frame and they didn't
> > want too many of those on the stack.  If it is a problem I have
> > some partially written code that would work around this but once
> > I realised Zero didn't need it I stopped working on it.
> 
> I'm not exactly sure how to proceed here.  Should we try to
> implement the missing parts of 6829195 or should we file a
> separate bug for Zero and push this?

I wouldn't want to make direct x86 and sparc support for this
a prerequisite for the Zero code going in.  If it's possible to
commit as a partial fix for 6829195 then we could do that, but
if partial fixes aren't possible then maybe make a new bug and
do it that way.

Cheers,
Gary

-- 
http://gbenson.net/

From tom.deneau at amd.com  Mon Apr 11 09:12:00 2011
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 11 Apr 2011 11:12:00 -0500
Subject: Review Request: 3DNow Prefetch Instruction Support 
Message-ID: <5EA33A275136844D843B73A29FB9A6A98672B134@SAUSEXMBP01.amd.com>

Hi all,

Please review this patch which changes the logic for detecting whether or not a processor supports the 3dnow prefetchw and prefetch instructions.   A separate CPUID bit (defined in about 2007) allows a processor to support 3dnow prefetch instructions without supporting the whole 3dnow instruction set.  The upcoming processors from AMD are the first that support 3dnow prefetch without supporting the 3dnow instruction set.

The webrev is at

  http://cr.openjdk.java.net/~tdeneau/3dnow-cpuid/webrev.01/

The logic change is really one small change in src/cpu/x86/vm/vm_version_x86.hpp but to clarify things I changed a function name from supports_3dnow() to supports_3dnow_prefetch() which is really what was meant all along.  This was the reason the other files changed.  I did not make any change in src/cpu/x86/vm/x86_64.ad since that was not checking for 3dnow support.

I do not have a bug id for this.

-- Tom Deneau, AMD




From christian.thalinger at oracle.com  Mon Apr 11 10:47:04 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 11 Apr 2011 19:47:04 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <20110411131640.GA8649@redhat.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
	<D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
	<20110405134616.GA3243@redhat.com>
	<E77F1601-18AB-4275-8504-4057C957E5C7@oracle.com>
	<20110411131640.GA8649@redhat.com>
Message-ID: <E3152561-8731-4C4A-8882-AC7B03B9E702@oracle.com>

On Apr 11, 2011, at 3:16 PM, Gary Benson wrote:
> Christian Thalinger wrote:
>> On Apr 5, 2011, at 3:46 PM, Gary Benson wrote:
>>> Christian Thalinger wrote:
>>>> On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
>>>>> John Rose wrote:
>>>>>> On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
>>>>>>> This webrev adds support for JSR 292 to Zero:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
>>>>>> 
>>>>>> Most impressive!  I think this matches the following
>>>>>> previously filed bug:
>>>>>> 
>>>>>> 6829195  JSR 292 needs to support the C++ interpreter
>>>>> 
>>>>> Partially, yes, in that it implements invokedynamic and
>>>>> fast_aldc* in the bytecode interpreter.  For the sparc or x86
>>>>> ports you would also need to write the method handle entries
>>>>> and add frame manager support for the call_method_handle
>>>>> message.
>>>> 
>>>> How much work would that be?
>>> 
>>> I'm not sure.  Actually, thinking about it, the method handle
>>> entries are already there (the template and C++ interpreters have
>>> the same ABI, no?)  You could check by trying to run the method
>>> handles tests.  If that's the case, the only extra bit is adding
>>> support for call_method_handle.  There's a potential trap,
>>> however, in that the calls to
>>> InterpreterRuntime::resolve_invokedynamic and
>>> InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run
>>> enter VM mode and end up reentering the C++ interpreter.  I don't
>>> know that the assembly language ports can handle this.  They're
>>> certainly written to avoid it, but that might be simply because
>>> BytecodeInterpreter::run has a huge stack frame and they didn't
>>> want too many of those on the stack.  If it is a problem I have
>>> some partially written code that would work around this but once
>>> I realised Zero didn't need it I stopped working on it.
>> 
>> I'm not exactly sure how to proceed here.  Should we try to
>> implement the missing parts of 6829195 or should we file a
>> separate bug for Zero and push this?
> 
> I wouldn't want to make direct x86 and sparc support for this
> a prerequisite for the Zero code going in.  If it's possible to
> commit as a partial fix for 6829195 then we could do that, but
> if partial fixes aren't possible then maybe make a new bug and
> do it that way.

Partial fixes are not possible, we need a new CR for that.   I will take care of it tomorrow.

-- Christian

From vladimir.kozlov at oracle.com  Mon Apr 11 14:24:57 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 11 Apr 2011 14:24:57 -0700
Subject: Review Request: 3DNow Prefetch Instruction Support
In-Reply-To: <5EA33A275136844D843B73A29FB9A6A98672B134@SAUSEXMBP01.amd.com>
References: <5EA33A275136844D843B73A29FB9A6A98672B134@SAUSEXMBP01.amd.com>
Message-ID: <4DA371A9.7080307@oracle.com>

Looks good. I filed 7035713 and will push this changes.

I had to remove one "%s" in feature srting output format since you removed 
"3dnowext". And we usually leave logical operator on first line:

!       if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) ||
!           (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0))
!         result |= CPU_3DNOW_PREFETCH;

Vladimir

Deneau, Tom wrote:
> Hi all,
> 
> Please review this patch which changes the logic for detecting whether or not a processor supports the 3dnow prefetchw and prefetch instructions.   A separate CPUID bit (defined in about 2007) allows a processor to support 3dnow prefetch instructions without supporting the whole 3dnow instruction set.  The upcoming processors from AMD are the first that support 3dnow prefetch without supporting the 3dnow instruction set.
> 
> The webrev is at
> 
>   http://cr.openjdk.java.net/~tdeneau/3dnow-cpuid/webrev.01/
> 
> The logic change is really one small change in src/cpu/x86/vm/vm_version_x86.hpp but to clarify things I changed a function name from supports_3dnow() to supports_3dnow_prefetch() which is really what was meant all along.  This was the reason the other files changed.  I did not make any change in src/cpu/x86/vm/x86_64.ad since that was not checking for 3dnow support.
> 
> I do not have a bug id for this.
> 
> -- Tom Deneau, AMD
> 
> 
> 

From vladimir.kozlov at oracle.com  Mon Apr 11 19:37:19 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Tue, 12 Apr 2011 02:37:19 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7035713: 3DNow Prefetch Instruction
	Support
Message-ID: <20110412023721.24CB7479C2@hg.openjdk.java.net>

Changeset: 15c9a0e16269
Author:    kvn
Date:      2011-04-11 15:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/15c9a0e16269

7035713: 3DNow Prefetch Instruction Support
Summary: The upcoming processors from AMD are the first that support 3dnow prefetch without supporting the 3dnow instruction set.
Reviewed-by: kvn
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/x86/vm/x86_32.ad


From christian.thalinger at oracle.com  Tue Apr 12 02:31:20 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 12 Apr 2011 11:31:20 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <E3152561-8731-4C4A-8882-AC7B03B9E702@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
	<D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
	<20110405134616.GA3243@redhat.com>
	<E77F1601-18AB-4275-8504-4057C957E5C7@oracle.com>
	<20110411131640.GA8649@redhat.com>
	<E3152561-8731-4C4A-8882-AC7B03B9E702@oracle.com>
Message-ID: <06CF7270-B1A9-46E2-9BE1-EC4AB97F386A@oracle.com>

On Apr 11, 2011, at 7:47 PM, Christian Thalinger wrote:
> On Apr 11, 2011, at 3:16 PM, Gary Benson wrote:
>> Christian Thalinger wrote:
>>> On Apr 5, 2011, at 3:46 PM, Gary Benson wrote:
>>>> Christian Thalinger wrote:
>>>>> On Apr 4, 2011, at 10:34 AM, Gary Benson wrote:
>>>>>> John Rose wrote:
>>>>>>> On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
>>>>>>>> This webrev adds support for JSR 292 to Zero:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
>>>>>>> 
>>>>>>> Most impressive!  I think this matches the following
>>>>>>> previously filed bug:
>>>>>>> 
>>>>>>> 6829195  JSR 292 needs to support the C++ interpreter
>>>>>> 
>>>>>> Partially, yes, in that it implements invokedynamic and
>>>>>> fast_aldc* in the bytecode interpreter.  For the sparc or x86
>>>>>> ports you would also need to write the method handle entries
>>>>>> and add frame manager support for the call_method_handle
>>>>>> message.
>>>>> 
>>>>> How much work would that be?
>>>> 
>>>> I'm not sure.  Actually, thinking about it, the method handle
>>>> entries are already there (the template and C++ interpreters have
>>>> the same ABI, no?)  You could check by trying to run the method
>>>> handles tests.  If that's the case, the only extra bit is adding
>>>> support for call_method_handle.  There's a potential trap,
>>>> however, in that the calls to
>>>> InterpreterRuntime::resolve_invokedynamic and
>>>> InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run
>>>> enter VM mode and end up reentering the C++ interpreter.  I don't
>>>> know that the assembly language ports can handle this.  They're
>>>> certainly written to avoid it, but that might be simply because
>>>> BytecodeInterpreter::run has a huge stack frame and they didn't
>>>> want too many of those on the stack.  If it is a problem I have
>>>> some partially written code that would work around this but once
>>>> I realised Zero didn't need it I stopped working on it.
>>> 
>>> I'm not exactly sure how to proceed here.  Should we try to
>>> implement the missing parts of 6829195 or should we file a
>>> separate bug for Zero and push this?
>> 
>> I wouldn't want to make direct x86 and sparc support for this
>> a prerequisite for the Zero code going in.  If it's possible to
>> commit as a partial fix for 6829195 then we could do that, but
>> if partial fixes aren't possible then maybe make a new bug and
>> do it that way.
> 
> Partial fixes are not possible, we need a new CR for that.   I will take care of it tomorrow.

7035870: JSR 292: Zero support

-- Christian

From christian.thalinger at oracle.com  Tue Apr 12 02:34:33 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 12 Apr 2011 11:34:33 +0200
Subject: Review Request: Zero JSR 292 support
In-Reply-To: <D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
References: <20110401143341.GG4281@redhat.com>
	<45C7AD77-6FE7-4B7C-B104-15902014E4CF@oracle.com>
	<20110404083459.GC3348@redhat.com>
	<D1917F71-0088-49C9-9776-7DB3A127BE62@oracle.com>
Message-ID: <FA9D0B81-8042-4107-925E-271B865AE88D@oracle.com>

On Apr 5, 2011, at 2:49 PM, Christian Thalinger wrote:
>>> Does this code pass the jtreg tests in jdk/test/java/lang/invoke/ ?
>> 
>> It passed their previous incarnation in jdk/test/java/dyn, with
>> this webrev applied to stop the tests disabling themselves:
>> 
>> http://cr.openjdk.java.net/~gbenson/zero-jsr292-tests/
> 
> John, can you add that code with one of your changes?

John, not sure you saw that email.  -- Christian

From christian.thalinger at oracle.com  Tue Apr 12 05:47:35 2011
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Tue, 12 Apr 2011 12:47:35 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7035870: JSR 292: Zero support
Message-ID: <20110412124737.3A5C0479E0@hg.openjdk.java.net>

Changeset: 4b95bbb36464
Author:    twisti
Date:      2011-04-12 02:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4b95bbb36464

7035870: JSR 292: Zero support
Summary: This adds support for JSR 292 to Zero.
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.hpp
! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/methodHandles_zero.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp


From gbenson at redhat.com  Tue Apr 12 06:03:50 2011
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 12 Apr 2011 14:03:50 +0100
Subject: hg: jdk7/hotspot-comp/hotspot: 7035870: JSR 292: Zero support
In-Reply-To: <20110412124737.3A5C0479E0@hg.openjdk.java.net>
References: <20110412124737.3A5C0479E0@hg.openjdk.java.net>
Message-ID: <20110412130350.GB2656@redhat.com>

christian.thalinger at oracle.com wrote:
> Changeset: 4b95bbb36464
> Author:    twisti
> Date:      2011-04-12 02:40 -0700
> URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4b95bbb36464
> 
> 7035870: JSR 292: Zero support
> Summary: This adds support for JSR 292 to Zero.
> Reviewed-by: twisti
> Contributed-by: Gary Benson <gbenson at redhat.com>
> 
> ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp
> ! src/cpu/zero/vm/cppInterpreter_zero.cpp
> ! src/cpu/zero/vm/cppInterpreter_zero.hpp
> ! src/cpu/zero/vm/interpreter_zero.cpp
> ! src/cpu/zero/vm/methodHandles_zero.cpp
> ! src/share/vm/interpreter/bytecodeInterpreter.cpp
> ! src/share/vm/interpreter/bytecodeInterpreter.hpp

Thanks Twisti!

-- 
http://gbenson.net/

From christian.thalinger at oracle.com  Tue Apr 12 08:49:12 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 12 Apr 2011 17:49:12 +0200
Subject: hg: jdk7/hotspot-comp/hotspot: 7035870: JSR 292: Zero support
In-Reply-To: <20110412130350.GB2656@redhat.com>
References: <20110412124737.3A5C0479E0@hg.openjdk.java.net>
	<20110412130350.GB2656@redhat.com>
Message-ID: <C0C0449B-224C-4A43-A375-03F6714022AD@oracle.com>

On Apr 12, 2011, at 3:03 PM, Gary Benson wrote:
> christian.thalinger at oracle.com wrote:
>> Changeset: 4b95bbb36464
>> Author:    twisti
>> Date:      2011-04-12 02:40 -0700
>> URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4b95bbb36464
>> 
>> 7035870: JSR 292: Zero support
>> Summary: This adds support for JSR 292 to Zero.
>> Reviewed-by: twisti
>> Contributed-by: Gary Benson <gbenson at redhat.com>
>> 
>> ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp
>> ! src/cpu/zero/vm/cppInterpreter_zero.cpp
>> ! src/cpu/zero/vm/cppInterpreter_zero.hpp
>> ! src/cpu/zero/vm/interpreter_zero.cpp
>> ! src/cpu/zero/vm/methodHandles_zero.cpp
>> ! src/share/vm/interpreter/bytecodeInterpreter.cpp
>> ! src/share/vm/interpreter/bytecodeInterpreter.hpp
> 
> Thanks Twisti!

Sure.  Thanks for implementing it!  -- Christian

From igor.veresov at oracle.com  Tue Apr 12 21:37:51 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 12 Apr 2011 21:37:51 -0700
Subject: review(XS): 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed:
	Bad frequency assignment in if
Message-ID: <4DA5289F.6000706@oracle.com>

The problem can occur in Parse::dynamic_branch_prediction(), where cnt 
can become negative if the block count is larger than max int. This is 
because the "sum" variable is an int and Block::count() returns uint, 
which if large enough will make "sum" become negative, causing in turn 
"cnt" to become negative.

I treated this problem by making the "sum" a float. Also, added guards 
to detect overflows of "taken" and "not_taken", protecting therefore 
against overflowing an int twice when they are added together.

Webrev: http://cr.openjdk.java.net/~iveresov/6988308/webrev.00/

Thanks!
igor

From vladimir.kozlov at oracle.com  Tue Apr 12 22:13:52 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 12 Apr 2011 22:13:52 -0700
Subject: review(XS): 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed:
	Bad frequency assignment in if
In-Reply-To: <4DA5289F.6000706@oracle.com>
References: <4DA5289F.6000706@oracle.com>
Message-ID: <4DA53110.3000108@oracle.com>

Looks good.

Vladimir

On 4/12/11 9:37 PM, Igor Veresov wrote:
> The problem can occur in Parse::dynamic_branch_prediction(), where cnt can become negative if the block count is larger
> than max int. This is because the "sum" variable is an int and Block::count() returns uint, which if large enough will
> make "sum" become negative, causing in turn "cnt" to become negative.
>
> I treated this problem by making the "sum" a float. Also, added guards to detect overflows of "taken" and "not_taken",
> protecting therefore against overflowing an int twice when they are added together.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/6988308/webrev.00/
>
> Thanks!
> igor

From christian.thalinger at oracle.com  Wed Apr 13 00:52:57 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 13 Apr 2011 09:52:57 +0200
Subject: review(XS): 6988308: assert((cnt > 0.0f) && (prob > 0.0f))
	failed: Bad frequency assignment in if
In-Reply-To: <4DA5289F.6000706@oracle.com>
References: <4DA5289F.6000706@oracle.com>
Message-ID: <50B8F4CC-0A29-454D-8098-B9220829496D@oracle.com>

On Apr 13, 2011, at 6:37 AM, Igor Veresov wrote:
> The problem can occur in Parse::dynamic_branch_prediction(), where cnt can become negative if the block count is larger than max int. This is because the "sum" variable is an int and Block::count() returns uint, which if large enough will make "sum" become negative, causing in turn "cnt" to become negative.
> 
> I treated this problem by making the "sum" a float. Also, added guards to detect overflows of "taken" and "not_taken", protecting therefore against overflowing an int twice when they are added together.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/6988308/webrev.00/

The change looks good and I have a question:  how often does the overflow of taken and not_taken counts happen?  

-- Christian

From xerxes at zafena.se  Wed Apr 13 03:41:10 2011
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Wed, 13 Apr 2011 12:41:10 +0200
Subject: Review Request: Shark  fails to find LLVM 2.9 System headers during
	build.
Message-ID: <4DA57DC6.6040803@zafena.se>

Forwarded from hotspot-dev.

Hi all,

In LLVM 2.9
llvm/System/Threading.h and llvm/System/Host.h
have been moved to
llvm/Support/Threading.h and llvm/Support/Host.h
http://llvm.org/viewvc/llvm-project?view=rev&revision=120298

This webrev fix:

  http://labb.zafena.se/openjdk/shark-llvm-2.9/

I don't have a bug id for this.

This are my first patch submission to hotspot-dev.
I have signed the SCA.
http://sca.java.net/CA_signatories.htm

Cheers and have a great day!
Xerxes


From christian.thalinger at oracle.com  Wed Apr 13 04:53:47 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 13 Apr 2011 13:53:47 +0200
Subject: Request for review (S): 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
Message-ID: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>

http://cr.openjdk.java.net/~twisti/7018355

7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
Reviewed-by:

There are a couple of unhandled oop usages over potential safepoints
in methodHandles.cpp.  Three of them could be found with
+CheckUnhandledOops, the other ones were either found via
visual-inspection or just were changed for the sake of safety.

src/share/vm/memory/genOopClosures.hpp
src/share/vm/prims/methodHandles.cpp


From john.cuthbertson at oracle.com  Wed Apr 13 10:08:48 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 13 Apr 2011 10:08:48 -0700
Subject: RFR(XS): 7035117: G1: nsk/stress/jni/jnistress002 fails with
	an assertion failure caused by changes for 7009266
In-Reply-To: <4D9F4E23.6060301@oracle.com>
References: <4D9F4E23.6060301@oracle.com>
Message-ID: <4DA5D8A0.8060703@oracle.com>

Hi Everyone,

I have a new webrev for this CR here: 
http://cr.openjdk.java.net/~johnc/7035117/webrev.1/

The changes include Tom's suggestion to use ConX in C2 code and the fix 
for the same test in tiered compilation/C1.

Testing: the failing test case, nsk tests, jprt.

Thanks,

JohnC

On 04/08/11 11:04, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers to look over the fix for this CR? 
> The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7035177/webrev.0/.
>
> The problem is that the node representing the offset (in an 
> Unsafe.getObject compilation) could be typed as a long and generating 
> the compare of offset against java_lang_ref_Reference::referent_offset 
> (typed as an int) caused an assertion failure about the mis-matching 
> types.
>
> The fix is to generate a suitably typed constant based upon the type 
> of "offset".
>
> Tested using the failing test case from the nightly tests.
>
> Thanks,
>
> JohnC
>


From john.cuthbertson at oracle.com  Wed Apr 13 10:16:32 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 13 Apr 2011 10:16:32 -0700
Subject: RFR (XS): 7036021: G1: build failure on win64 and linux with hs21
	in jdk6 build environment
Message-ID: <4DA5DA70.9060500@oracle.com>

Hi Everyone,

Can I have a couple of volunteers to review these changes? The webrev 
can be found at: http://cr.openjdk.java.net/~johnc/7036021/webrev.0/.

Issue: Some of the the changes for 7026932 and 7009266 do cause 
compilation errors when built with the jdk6 build tools. The first is 
missing parentheses around an expression and the second is passing an 
uncasted negative one to a unsigned which has been substituted with 
max_juint.

Thanks,

JohnC

From christian.thalinger at oracle.com  Wed Apr 13 04:53:47 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 13 Apr 2011 13:53:47 +0200
Subject: Request for review (S): 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
Message-ID: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>

[Resending.]

http://cr.openjdk.java.net/~twisti/7018355

7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
Reviewed-by:

There are a couple of unhandled oop usages over potential safepoints
in methodHandles.cpp.  Three of them could be found with
+CheckUnhandledOops, the other ones were either found via
visual-inspection or just were changed for the sake of safety.

src/share/vm/memory/genOopClosures.hpp
src/share/vm/prims/methodHandles.cpp


From vladimir.kozlov at oracle.com  Wed Apr 13 11:58:20 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Apr 2011 11:58:20 -0700
Subject: RFR (XS): 7036021: G1: build failure on win64 and linux with
	hs21 in jdk6 build environment
In-Reply-To: <4DA5DA70.9060500@oracle.com>
References: <4DA5DA70.9060500@oracle.com>
Message-ID: <4DA5F24C.1080701@oracle.com>

Looks good. Why G1 code does not use juint type instead of unsigned int?

Vladimir

John Cuthbertson wrote:
> Hi Everyone,
> 
> Can I have a couple of volunteers to review these changes? The webrev 
> can be found at: http://cr.openjdk.java.net/~johnc/7036021/webrev.0/.
> 
> Issue: Some of the the changes for 7026932 and 7009266 do cause 
> compilation errors when built with the jdk6 build tools. The first is 
> missing parentheses around an expression and the second is passing an 
> uncasted negative one to a unsigned which has been substituted with 
> max_juint.
> 
> Thanks,
> 
> JohnC

From vladimir.kozlov at oracle.com  Wed Apr 13 12:01:06 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Apr 2011 12:01:06 -0700
Subject: Request for review (S): 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
In-Reply-To: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>
References: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>
Message-ID: <4DA5F2F2.8000405@oracle.com>

Looks good.

Vladimir

Christian Thalinger wrote:
> [Resending.]
> 
> http://cr.openjdk.java.net/~twisti/7018355
> 
> 7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
> Reviewed-by:
> 
> There are a couple of unhandled oop usages over potential safepoints
> in methodHandles.cpp.  Three of them could be found with
> +CheckUnhandledOops, the other ones were either found via
> visual-inspection or just were changed for the sake of safety.
> 
> src/share/vm/memory/genOopClosures.hpp
> src/share/vm/prims/methodHandles.cpp
> 

From igor.veresov at oracle.com  Wed Apr 13 12:53:29 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 13 Apr 2011 12:53:29 -0700
Subject: review(XS): 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed:
	Bad frequency assignment in if
In-Reply-To: <50B8F4CC-0A29-454D-8098-B9220829496D@oracle.com>
References: <4DA5289F.6000706@oracle.com>
	<50B8F4CC-0A29-454D-8098-B9220829496D@oracle.com>
Message-ID: <4DA5FF39.6080203@oracle.com>

On 4/13/11 12:52 AM, Christian Thalinger wrote:
> On Apr 13, 2011, at 6:37 AM, Igor Veresov wrote:
>> The problem can occur in Parse::dynamic_branch_prediction(), where cnt can become negative if the block count is larger than max int. This is because the "sum" variable is an int and Block::count() returns uint, which if large enough will make "sum" become negative, causing in turn "cnt" to become negative.
>>
>> I treated this problem by making the "sum" a float. Also, added guards to detect overflows of "taken" and "not_taken", protecting therefore against overflowing an int twice when they are added together.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/6988308/webrev.00/
>
> The change looks good and I have a question:  how often does the overflow of taken and not_taken counts happen?

With interpreter-only profiling it will actually stop at -1, because it 
adds one and then subtracts the carry thus keeping it from turning over. 
With tiered I yet have to take care of this issue, I'm afraid - 
currently it will overflow.

But it is quite an infrequent situation. Typically it would happen if 
the code cache is full and we stop compiling and a method is stuck in 
C1+profiling state or is profiled in the interpreter.

igor


>
> -- Christian


From christian.thalinger at oracle.com  Wed Apr 13 14:11:11 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 13 Apr 2011 23:11:11 +0200
Subject: Request for review (S): 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
In-Reply-To: <4DA5F2F2.8000405@oracle.com>
References: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>
	<4DA5F2F2.8000405@oracle.com>
Message-ID: <1BC34C70-B7CF-47FC-ACD2-0FCF160F6120@oracle.com>

On Apr 13, 2011, at 9:01 PM, Vladimir Kozlov wrote:
> Looks good.

Thanks, Vladimir.  -- Christian

> 
> Vladimir
> 
> Christian Thalinger wrote:
>> [Resending.]
>> http://cr.openjdk.java.net/~twisti/7018355
>> 7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
>> Reviewed-by:
>> There are a couple of unhandled oop usages over potential safepoints
>> in methodHandles.cpp.  Three of them could be found with
>> +CheckUnhandledOops, the other ones were either found via
>> visual-inspection or just were changed for the sake of safety.
>> src/share/vm/memory/genOopClosures.hpp
>> src/share/vm/prims/methodHandles.cpp



From igor.veresov at oracle.com  Wed Apr 13 14:15:41 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 13 Apr 2011 14:15:41 -0700
Subject: review(XS): 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed:
	Bad frequency assignment in if
In-Reply-To: <4DA53110.3000108@oracle.com>
References: <4DA5289F.6000706@oracle.com> <4DA53110.3000108@oracle.com>
Message-ID: <4DA6127D.8050209@oracle.com>

Thanks Vladimir and Christian!

igor

On 4/12/11 10:13 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir
>
> On 4/12/11 9:37 PM, Igor Veresov wrote:
>> The problem can occur in Parse::dynamic_branch_prediction(), where cnt
>> can become negative if the block count is larger
>> than max int. This is because the "sum" variable is an int and
>> Block::count() returns uint, which if large enough will
>> make "sum" become negative, causing in turn "cnt" to become negative.
>>
>> I treated this problem by making the "sum" a float. Also, added guards
>> to detect overflows of "taken" and "not_taken",
>> protecting therefore against overflowing an int twice when they are
>> added together.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/6988308/webrev.00/
>>
>> Thanks!
>> igor


From igor.veresov at oracle.com  Wed Apr 13 18:53:33 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 13 Apr 2011 18:53:33 -0700
Subject: review(S): 7036236: VM crashes assert((!inside_attrs()) ||
	is_error_reported()) failed ...
Message-ID: <4DA6539D.6050902@oracle.com>

Assert is caused by a race: CompileBroker::handle_full_code_cache() can 
be called in different contexts, so a lock is required when we're 
printing to xtty, since it's stateful. So I put the xml element 
construction under a tty lock.

However, CodeCache::log_state() calls largest_free_block() that will 
unlock the tty lock, which will cause tearing and the same assertion 
failure (this will also happen in NMethodSweeper::log_sweep()). To 
alleviate this problem I moved the call to log_state() before the tty 
lock is taken and made it do the output to a stringStream, which is 
printed later under the tty lock. This way we decouple the tty lock and 
CodeCache_lock in largest_free_block().

Also removed ttyUnlocker from largest_free_block(), since it's no longer 
needed.

Webrev: http://cr.openjdk.java.net/~iveresov/7036236/webrev.00/

Thanks!
igor

From igor.veresov at oracle.com  Wed Apr 13 18:57:21 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 13 Apr 2011 18:57:21 -0700
Subject: review(S): 7036236: VM crashes assert((!inside_attrs()) ||
	is_error_reported()) failed ...
Message-ID: <4DA65481.3060300@oracle.com>

[resending]

Assert is caused by a race: CompileBroker::handle_full_code_cache() can 
be called in different contexts, so a lock is required when we're 
printing to xtty, since it's stateful. So I put the xml element 
construction under a tty lock.

However, CodeCache::log_state() calls largest_free_block() that will 
unlock the tty lock, which will cause tearing and the same assertion 
failure (this will also happen in NMethodSweeper::log_sweep()). To 
alleviate this problem I moved the call to log_state() before the tty 
lock is taken and made it do the output to a stringStream, which is 
printed later under the tty lock. This way we decouple the tty lock and 
CodeCache_lock in largest_free_block().

Also removed ttyUnlocker from largest_free_block(), since it's no longer 
needed.

Webrev: http://cr.openjdk.java.net/~iveresov/7036236/webrev.00/

Thanks!
igor

From igor.veresov at oracle.com  Wed Apr 13 19:49:32 2011
From: igor.veresov at oracle.com (igor.veresov at oracle.com)
Date: Thu, 14 Apr 2011 02:49:32 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 6988308: assert((cnt > 0.0f) && (prob
	> 0.0f)) failed: Bad frequency assignment in if
Message-ID: <20110414024939.BC00847A6F@hg.openjdk.java.net>

Changeset: 3a808be061ff
Author:    iveresov
Date:      2011-04-13 14:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3a808be061ff

6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed: Bad frequency assignment in if
Summary: Make sure cnt doesn't become negative and integer overflow doesn't happen.
Reviewed-by: kvn, twisti

! src/share/vm/opto/parse2.cpp


From vladimir.kozlov at oracle.com  Wed Apr 13 21:37:30 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Apr 2011 21:37:30 -0700
Subject: review(S): 7036236: VM crashes assert((!inside_attrs()) ||
	is_error_reported()) failed ...
In-Reply-To: <4DA65481.3060300@oracle.com>
References: <4DA65481.3060300@oracle.com>
Message-ID: <4DA67A0A.4070400@oracle.com>

Looks good.

Vladimir

On 4/13/11 6:57 PM, Igor Veresov wrote:
> [resending]
>
> Assert is caused by a race: CompileBroker::handle_full_code_cache() can be called in different contexts, so a lock is
> required when we're printing to xtty, since it's stateful. So I put the xml element construction under a tty lock.
>
> However, CodeCache::log_state() calls largest_free_block() that will unlock the tty lock, which will cause tearing and
> the same assertion failure (this will also happen in NMethodSweeper::log_sweep()). To alleviate this problem I moved the
> call to log_state() before the tty lock is taken and made it do the output to a stringStream, which is printed later
> under the tty lock. This way we decouple the tty lock and CodeCache_lock in largest_free_block().
>
> Also removed ttyUnlocker from largest_free_block(), since it's no longer needed.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/7036236/webrev.00/
>
> Thanks!
> igor

From igor.veresov at oracle.com  Wed Apr 13 22:00:06 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 13 Apr 2011 22:00:06 -0700
Subject: review(S): 7036236: VM crashes assert((!inside_attrs()) ||
	is_error_reported()) failed ...
In-Reply-To: <4DA67A0A.4070400@oracle.com>
References: <4DA65481.3060300@oracle.com> <4DA67A0A.4070400@oracle.com>
Message-ID: <4DA67F56.6060403@oracle.com>

Thanks!

On 4/13/11 9:37 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir
>
> On 4/13/11 6:57 PM, Igor Veresov wrote:
>> [resending]
>>
>> Assert is caused by a race: CompileBroker::handle_full_code_cache()
>> can be called in different contexts, so a lock is
>> required when we're printing to xtty, since it's stateful. So I put
>> the xml element construction under a tty lock.
>>
>> However, CodeCache::log_state() calls largest_free_block() that will
>> unlock the tty lock, which will cause tearing and
>> the same assertion failure (this will also happen in
>> NMethodSweeper::log_sweep()). To alleviate this problem I moved the
>> call to log_state() before the tty lock is taken and made it do the
>> output to a stringStream, which is printed later
>> under the tty lock. This way we decouple the tty lock and
>> CodeCache_lock in largest_free_block().
>>
>> Also removed ttyUnlocker from largest_free_block(), since it's no
>> longer needed.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/7036236/webrev.00/
>>
>> Thanks!
>> igor


From christian.thalinger at oracle.com  Thu Apr 14 02:12:37 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 14 Apr 2011 11:12:37 +0200
Subject: RFR(XS): 7035117: G1: nsk/stress/jni/jnistress002 fails with an
	assertion failure caused by changes for 7009266
In-Reply-To: <4DA5D8A0.8060703@oracle.com>
References: <4D9F4E23.6060301@oracle.com> <4DA5D8A0.8060703@oracle.com>
Message-ID: <7771C78D-C2DF-41FF-9C51-155EC3AA16F1@oracle.com>

On Apr 13, 2011, at 7:08 PM, John Cuthbertson wrote:
> Hi Everyone,
> 
> I have a new webrev for this CR here: http://cr.openjdk.java.net/~johnc/7035117/webrev.1/
> 
> The changes include Tom's suggestion to use ConX in C2 code and the fix for the same test in tiered compilation/C1.

-  Register thread_reg = thread()->as_register();
+  Register thread_reg = NOT_LP64(thread()->as_register()) LP64_ONLY(thread()->as_register_lo());

I'm not an expert here but could you use as_pointer_register here instead?

-- Christian

> 
> Testing: the failing test case, nsk tests, jprt.
> 
> Thanks,
> 
> JohnC
> 
> On 04/08/11 11:04, John Cuthbertson wrote:
>> Hi Everyone,
>> 
>> Can I have a couple of volunteers to look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7035177/webrev.0/.
>> 
>> The problem is that the node representing the offset (in an Unsafe.getObject compilation) could be typed as a long and generating the compare of offset against java_lang_ref_Reference::referent_offset (typed as an int) caused an assertion failure about the mis-matching types.
>> 
>> The fix is to generate a suitably typed constant based upon the type of "offset".
>> 
>> Tested using the failing test case from the nightly tests.
>> 
>> Thanks,
>> 
>> JohnC



From igor.veresov at oracle.com  Thu Apr 14 06:43:52 2011
From: igor.veresov at oracle.com (igor.veresov at oracle.com)
Date: Thu, 14 Apr 2011 13:43:52 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7036236: VM crashes
	assert((!inside_attrs()) || is_error_reported()) failed ...
Message-ID: <20110414134354.CF03B47A9C@hg.openjdk.java.net>

Changeset: dbccacb79c63
Author:    iveresov
Date:      2011-04-14 00:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dbccacb79c63

7036236: VM crashes assert((!inside_attrs()) || is_error_reported()) failed ...
Summary: Eliminate the race condition.
Reviewed-by: kvn

! src/share/vm/code/codeCache.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/runtime/sweeper.cpp


From christian.thalinger at oracle.com  Thu Apr 14 08:46:24 2011
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Thu, 14 Apr 2011 15:46:24 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20110414154628.41BFD47AA1@hg.openjdk.java.net>

Changeset: 1fcd6e9c3965
Author:    twisti
Date:      2011-04-14 01:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1fcd6e9c3965

7036220: Shark fails to find LLVM 2.9 System headers during build
Reviewed-by: gbenson, twisti
Contributed-by: Xerxes Ranby <xerxes at zafena.se>

! src/share/vm/shark/llvmHeaders.hpp

Changeset: e9b9554f7fc3
Author:    twisti
Date:      2011-04-14 06:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e9b9554f7fc3

Merge



From christian.thalinger at oracle.com  Fri Apr 15 02:44:08 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 15 Apr 2011 11:44:08 +0200
Subject: Request for review (S): 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
In-Reply-To: <1BC34C70-B7CF-47FC-ACD2-0FCF160F6120@oracle.com>
References: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>
	<4DA5F2F2.8000405@oracle.com>
	<1BC34C70-B7CF-47FC-ACD2-0FCF160F6120@oracle.com>
Message-ID: <8F97B0D7-091C-402B-B188-C29C90C1B5E8@oracle.com>

John suggested:

"Consider changing return-by-reference of klassOop to rbr of a handle. Avoid the scoped oop temp."

So I changed MethodHandles::decode_* function to take a KlassHandle and return a methodHandle instead of oops which makes the uses of these methods simpler.

webrev udpated.

-- Christian

On Apr 13, 2011, at 11:11 PM, Christian Thalinger wrote:
> On Apr 13, 2011, at 9:01 PM, Vladimir Kozlov wrote:
>> Looks good.
> 
> Thanks, Vladimir.  -- Christian
> 
>> 
>> Vladimir
>> 
>> Christian Thalinger wrote:
>>> [Resending.]
>>> http://cr.openjdk.java.net/~twisti/7018355
>>> 7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
>>> Reviewed-by:
>>> There are a couple of unhandled oop usages over potential safepoints
>>> in methodHandles.cpp.  Three of them could be found with
>>> +CheckUnhandledOops, the other ones were either found via
>>> visual-inspection or just were changed for the sake of safety.
>>> src/share/vm/memory/genOopClosures.hpp
>>> src/share/vm/prims/methodHandles.cpp



From christian.thalinger at oracle.com  Fri Apr 15 04:49:02 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 15 Apr 2011 13:49:02 +0200
Subject: Request for review (XS): 7036960: TemplateTable::fast_aldc in
	templateTable_x86_64.cpp uses movptr instead of load_klass
Message-ID: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>

http://cr.openjdk.java.net/~twisti/7036960/

7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
Reviewed-by:

The fix is to replace movptr with load_klass.

Additionally I changed all occurrences of movptr instructions loading
the class of an oop with load_klass in templateTable_x86_32.cpp (to be
some consistent).

src/cpu/x86/vm/templateTable_x86_32.cpp
src/cpu/x86/vm/templateTable_x86_64.cpp


From vladimir.kozlov at oracle.com  Fri Apr 15 08:42:06 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 15 Apr 2011 08:42:06 -0700
Subject: Request for review (S): 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
In-Reply-To: <8F97B0D7-091C-402B-B188-C29C90C1B5E8@oracle.com>
References: <33349155-62B6-47EF-8C7F-531C2224BE5F@oracle.com>	<4DA5F2F2.8000405@oracle.com>	<1BC34C70-B7CF-47FC-ACD2-0FCF160F6120@oracle.com>
	<8F97B0D7-091C-402B-B188-C29C90C1B5E8@oracle.com>
Message-ID: <4DA8674E.9080802@oracle.com>

Looks fine.

Vladimir

Christian Thalinger wrote:
> John suggested:
> 
> "Consider changing return-by-reference of klassOop to rbr of a handle. Avoid the scoped oop temp."
> 
> So I changed MethodHandles::decode_* function to take a KlassHandle and return a methodHandle instead of oops which makes the uses of these methods simpler.
> 
> webrev udpated.
> 
> -- Christian
> 
> On Apr 13, 2011, at 11:11 PM, Christian Thalinger wrote:
>> On Apr 13, 2011, at 9:01 PM, Vladimir Kozlov wrote:
>>> Looks good.
>> Thanks, Vladimir.  -- Christian
>>
>>> Vladimir
>>>
>>> Christian Thalinger wrote:
>>>> [Resending.]
>>>> http://cr.openjdk.java.net/~twisti/7018355
>>>> 7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
>>>> Reviewed-by:
>>>> There are a couple of unhandled oop usages over potential safepoints
>>>> in methodHandles.cpp.  Three of them could be found with
>>>> +CheckUnhandledOops, the other ones were either found via
>>>> visual-inspection or just were changed for the sake of safety.
>>>> src/share/vm/memory/genOopClosures.hpp
>>>> src/share/vm/prims/methodHandles.cpp
> 
> 

From vladimir.kozlov at oracle.com  Fri Apr 15 08:43:10 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 15 Apr 2011 08:43:10 -0700
Subject: Request for review (XS): 7036960: TemplateTable::fast_aldc in
	templateTable_x86_64.cpp uses movptr instead of load_klass
In-Reply-To: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
References: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
Message-ID: <4DA8678E.1020900@oracle.com>

Looks good.

Vladimir

Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/7036960/
> 
> 7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
> Reviewed-by:
> 
> The fix is to replace movptr with load_klass.
> 
> Additionally I changed all occurrences of movptr instructions loading
> the class of an oop with load_klass in templateTable_x86_32.cpp (to be
> some consistent).
> 
> src/cpu/x86/vm/templateTable_x86_32.cpp
> src/cpu/x86/vm/templateTable_x86_64.cpp
> 

From john.cuthbertson at oracle.com  Fri Apr 15 10:53:33 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 15 Apr 2011 10:53:33 -0700
Subject: RFR(XXS): 7036706 G1: Use LIR_OprDesc::as_pointer_register in code
	changes for 7035117
Message-ID: <4DA8861D.1010806@oracle.com>

Hi Everyone,

  Can I have a couple of volunteers to review this change? The webrev 
can be found at: http://cr.openjdk.java.net/~johnc/7036706/webrev.0/

The change incorporates Christian's suggestion to use 
LIR_OprDesc::as_pointer_register() to define thread_reg in the C1 code 
stubs for Unsafe.getObject.

Testing: nsk stress tests (including jni stress tests) with 
TieredCompilation on both sparc64 and x64.

Thanks

JohnC

From igor.veresov at oracle.com  Fri Apr 15 11:22:05 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 15 Apr 2011 11:22:05 -0700
Subject: Request for review (XS): 7036960: TemplateTable::fast_aldc in
	templateTable_x86_64.cpp uses movptr instead of load_klass
In-Reply-To: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
References: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
Message-ID: <4DA88CCD.5050606@oracle.com>

Looks good.

igor

On 4/15/11 4:49 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/7036960/
>
> 7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
> Reviewed-by:
>
> The fix is to replace movptr with load_klass.
>
> Additionally I changed all occurrences of movptr instructions loading
> the class of an oop with load_klass in templateTable_x86_32.cpp (to be
> some consistent).
>
> src/cpu/x86/vm/templateTable_x86_32.cpp
> src/cpu/x86/vm/templateTable_x86_64.cpp
>


From igor.veresov at oracle.com  Fri Apr 15 11:24:13 2011
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 15 Apr 2011 11:24:13 -0700
Subject: RFR(XXS): 7036706 G1: Use LIR_OprDesc::as_pointer_register in
	code changes for 7035117
In-Reply-To: <4DA8861D.1010806@oracle.com>
References: <4DA8861D.1010806@oracle.com>
Message-ID: <4DA88D4D.2000908@oracle.com>

Looks good. Sorry for not spotting it the first time.

igor

On 4/15/11 10:53 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers to review this change? The webrev can
> be found at: http://cr.openjdk.java.net/~johnc/7036706/webrev.0/
>
> The change incorporates Christian's suggestion to use
> LIR_OprDesc::as_pointer_register() to define thread_reg in the C1 code
> stubs for Unsafe.getObject.
>
> Testing: nsk stress tests (including jni stress tests) with
> TieredCompilation on both sparc64 and x64.
>
> Thanks
>
> JohnC


From john.r.rose at oracle.com  Sat Apr 16 05:14:45 2011
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Sat, 16 Apr 2011 12:14:45 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 10 new changesets
Message-ID: <20110416121504.3349947B35@hg.openjdk.java.net>

Changeset: 677234770800
Author:    dsamersoff
Date:      2011-03-30 19:38 +0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/677234770800

7017193: Small memory leak in get_stack_bounds os::create_stack_guard_pages
Summary: getline() returns -1 but still allocate memory for str
Reviewed-by: dcubed, coleenp

! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp

Changeset: b025bffd6c2c
Author:    dholmes
Date:      2011-03-31 06:54 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b025bffd6c2c

7032775: Include Shark code in the build again
Reviewed-by: ohair
Contributed-by: gbenson at redhat.com, ahughes at redhat.com

! make/linux/makefiles/vm.make

Changeset: 37be97a58393
Author:    andrew
Date:      2011-04-01 15:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/37be97a58393

7010849: 5/5 Extraneous javac source/target options when building sa-jdi
Summary: Make code changes necessary to get rid of the '-source 1.4 -target 1.4' options.
Reviewed-by: dholmes, dcubed

! agent/src/share/classes/sun/jvm/hotspot/HelloWorld.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ByteValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/CharValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ConnectorImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/DoubleValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/FieldImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/FloatValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/IntegerValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/LocalVariableImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/LocationImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/LongValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/MethodImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ShortValueImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java
! make/linux/makefiles/sa.make
! make/solaris/makefiles/sa.make
! make/windows/makefiles/sa.make

Changeset: 7144a1d6e0a9
Author:    kamg
Date:      2011-03-31 08:08 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7144a1d6e0a9

7030388: JCK test failed to reject invalid class check01304m10n.
Summary: Restrict fix for 7020118 to only when checking exception handlers
Reviewed-by: dcubed, dholmes

! src/share/vm/classfile/stackMapFrame.cpp
! src/share/vm/classfile/stackMapFrame.hpp
! src/share/vm/classfile/stackMapTable.cpp

Changeset: 11427f216063
Author:    dholmes
Date:      2011-04-04 18:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/11427f216063

7009276: Add -XX:+IgnoreUnrecognizedVMOptions to several tests
Reviewed-by: kvn

! test/compiler/6795161/Test.java

Changeset: 1dac0f3af89f
Author:    ohair
Date:      2011-04-07 20:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1dac0f3af89f

7019210: Fix misc references to /bugreport websites
Reviewed-by: skannan

! src/share/vm/runtime/arguments.cpp

Changeset: c49c3947b98a
Author:    brutisso
Date:      2011-04-11 11:12 +0200
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c49c3947b98a

7034625: Product builds in Visual Studio projects should produce full symbol information
Summary: Add the /debug flag to the linker command in Visual Studio
Reviewed-by: mgronlun, poonam, hosterda

! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java

Changeset: 6a615eae2f34
Author:    dholmes
Date:      2011-04-12 02:53 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6a615eae2f34

7034585: Adjust fillInStackTrace filtering to assist 6998871
Summary: Allow for one or more fillInStackTrace frames to be skipped
Reviewed-by: mchung, kvn

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/vmSymbols.hpp

Changeset: 3449f5e02cc4
Author:    coleenp
Date:      2011-04-12 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3449f5e02cc4

Merge

! make/linux/makefiles/vm.make
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/stackMapFrame.cpp
! src/share/vm/classfile/stackMapFrame.hpp
! src/share/vm/classfile/stackMapTable.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 97e8046e2562
Author:    jrose
Date:      2011-04-15 08:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/97e8046e2562

Merge



From christian.thalinger at oracle.com  Mon Apr 18 06:44:42 2011
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Mon, 18 Apr 2011 13:44:42 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7018355: JSR 292: VM crash in
	DefNewGeneration::copy_to_survivor_space
Message-ID: <20110418134444.DF52347BC6@hg.openjdk.java.net>

Changeset: 2a23b1b5a0a8
Author:    twisti
Date:      2011-04-18 01:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a23b1b5a0a8

7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciMethod.hpp
! src/share/vm/memory/genOopClosures.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/sharedRuntime.cpp


From tom.rodriguez at oracle.com  Mon Apr 18 10:39:25 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 18 Apr 2011 10:39:25 -0700
Subject: Request for review (XS): 7036960: TemplateTable::fast_aldc in
	templateTable_x86_64.cpp uses movptr instead of load_klass
In-Reply-To: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
References: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
Message-ID: <FEA97CD3-429A-48F7-997C-3EC085293E15@oracle.com>

We should consider hiding klass_offset_in_bytes from most code in the system so that we are forced to use the appropriate MacroAssembler wrappers.  We will probably need to add some more wrappers to cover everything.  I wouldn't be surprised if there are more problems like this lurking.

tom

On Apr 15, 2011, at 4:49 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/7036960/
> 
> 7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
> Reviewed-by:
> 
> The fix is to replace movptr with load_klass.
> 
> Additionally I changed all occurrences of movptr instructions loading
> the class of an oop with load_klass in templateTable_x86_32.cpp (to be
> some consistent).
> 
> src/cpu/x86/vm/templateTable_x86_32.cpp
> src/cpu/x86/vm/templateTable_x86_64.cpp
> 


From christian.thalinger at oracle.com  Tue Apr 19 01:03:57 2011
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Tue, 19 Apr 2011 08:03:57 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7036960: TemplateTable::fast_aldc in
	templateTable_x86_64.cpp uses movptr instead of load_klass
Message-ID: <20110419080359.AC94447BF9@hg.openjdk.java.net>

Changeset: bbe95b4337f1
Author:    twisti
Date:      2011-04-18 06:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bbe95b4337f1

7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp


From christian.thalinger at oracle.com  Tue Apr 19 01:33:22 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 19 Apr 2011 10:33:22 +0200
Subject: Request for review (XS): 7036960: TemplateTable::fast_aldc in
	templateTable_x86_64.cpp uses movptr instead of load_klass
In-Reply-To: <FEA97CD3-429A-48F7-997C-3EC085293E15@oracle.com>
References: <40EBF91C-A409-4BF4-A263-D66FF957076C@oracle.com>
	<FEA97CD3-429A-48F7-997C-3EC085293E15@oracle.com>
Message-ID: <9B07125D-584E-40F6-8816-34B950224487@oracle.com>

On Apr 18, 2011, at 7:39 PM, Tom Rodriguez wrote:
> We should consider hiding klass_offset_in_bytes from most code in the system so that we are forced to use the appropriate MacroAssembler wrappers.  We will probably need to add some more wrappers to cover everything.  I wouldn't be surprised if there are more problems like this lurking.

I agree, we should do that.  -- Christian

> 
> tom
> 
> On Apr 15, 2011, at 4:49 AM, Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/7036960/
>> 
>> 7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
>> Reviewed-by:
>> 
>> The fix is to replace movptr with load_klass.
>> 
>> Additionally I changed all occurrences of movptr instructions loading
>> the class of an oop with load_klass in templateTable_x86_32.cpp (to be
>> some consistent).
>> 
>> src/cpu/x86/vm/templateTable_x86_32.cpp
>> src/cpu/x86/vm/templateTable_x86_64.cpp



From vitalyd at gmail.com  Tue Apr 19 05:47:08 2011
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 19 Apr 2011 08:47:08 -0400
Subject: support for SIMD in Hotspot (c2)
In-Reply-To: <BANLkTimn2+N7BWanX3M8FZgZdeatt4prFw@mail.gmail.com>
References: <BANLkTimn2+N7BWanX3M8FZgZdeatt4prFw@mail.gmail.com>
Message-ID: <BANLkTinAEyXJ_VkTj4DxKcQWKmTh=6fTEQ@mail.gmail.com>

Hi all,

In case anyone with info missed the original email, trying again :).

Thanks,

Vitaly

On Wed, Apr 6, 2011 at 1:35 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi guys,
>
> Are there any current plans to support SIMD SSE/AVX vector ops in c2 (i.e.
> loop vectorization transforms)? I came across a few related Oracle(Sun) RFEs
> in the database, saw the superword.hpp/cpp source in the OpenJDK repository,
> and did a bit of googl'ing but cannot tell where this stands at the moment.
>
> Thanks,
>
> Vitaly
>
>


-- 
Vitaly
617-548-7007 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110419/8325fe25/attachment.html 

From tom.deneau at amd.com  Tue Apr 19 08:43:23 2011
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 19 Apr 2011 10:43:23 -0500
Subject: Review Request: Further AMD Family 15h Defaults
Message-ID: <5EA33A275136844D843B73A29FB9A6A986922655@SAUSEXMBP01.amd.com>

Hi all,

Please review this patch which changes a few more defaults for the AMD family 15h processors.

The webrev is at

http://cr.openjdk.java.net/~tdeneau/bd-defaults-part2/webrev.01/

   * A previous patch made the default AllocationPrefetchStyle
     style 0 (no prefetch).  Here we add that if a different style
     is specified and a prefetch instruction type is not explicitly specified,
     the default prefetch instruction will be PREFETCHW.

   * UseXMMForArrayCopy and UseUnalignedLoadStores default to true

I do not have a bug id for this.

-- Tom Deneau, AMD




From vladimir.kozlov at oracle.com  Tue Apr 19 10:02:40 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 19 Apr 2011 10:02:40 -0700
Subject: Review Request: Further AMD Family 15h Defaults
In-Reply-To: <5EA33A275136844D843B73A29FB9A6A986922655@SAUSEXMBP01.amd.com>
References: <5EA33A275136844D843B73A29FB9A6A986922655@SAUSEXMBP01.amd.com>
Message-ID: <4DADC030.1030609@oracle.com>

Looks good. I filed 7037812 and created changeset. It is in queue to test and push.

Tom, if you have other changes coming make it soon.

Vladimir

Deneau, Tom wrote:
> Hi all,
> 
> Please review this patch which changes a few more defaults for the AMD family 15h processors.
> 
> The webrev is at
> 
> http://cr.openjdk.java.net/~tdeneau/bd-defaults-part2/webrev.01/
> 
>    * A previous patch made the default AllocationPrefetchStyle
>      style 0 (no prefetch).  Here we add that if a different style
>      is specified and a prefetch instruction type is not explicitly specified,
>      the default prefetch instruction will be PREFETCHW.
> 
>    * UseXMMForArrayCopy and UseUnalignedLoadStores default to true
> 
> I do not have a bug id for this.
> 
> -- Tom Deneau, AMD
> 
> 
> 

From vladimir.kozlov at oracle.com  Tue Apr 19 15:34:41 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Tue, 19 Apr 2011 22:34:41 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7037812: few more defaults changes for
	new AMD processors
Message-ID: <20110419223443.82D5447C2B@hg.openjdk.java.net>

Changeset: 2a34a4fbc52c
Author:    kvn
Date:      2011-04-19 09:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a34a4fbc52c

7037812: few more defaults changes for new AMD processors
Summary: use PREFETCHW as default prefetch instruction, set UseXMMForArrayCopy and UseUnalignedLoadStores to true by default.
Reviewed-by: kvn
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/vm_version_x86.cpp


From tom.rodriguez at oracle.com  Tue Apr 19 16:31:15 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 19 Apr 2011 16:31:15 -0700
Subject: review (XS) for 7009346: java/dyn/InvokeDynamicPrintArgs.java fails
	with NPE on solaris-sparc with -Xcomp
Message-ID: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>

http://cr.openjdk.java.net/~never/7009346

7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
Reviewed-by:

The invokespecial method handle adapter attempts to null check its
argument before the invoke but it's reading the wrong value so it
occasionally throws a spurious NPE.  The fix is to make it look like
all the other method handle code that's loading the receiver.  Tested
with failing test case.


From vladimir.kozlov at oracle.com  Tue Apr 19 16:35:57 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 19 Apr 2011 16:35:57 -0700
Subject: review (XS) for 7009346: java/dyn/InvokeDynamicPrintArgs.java
	fails with NPE on solaris-sparc with -Xcomp
In-Reply-To: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>
References: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>
Message-ID: <4DAE1C5D.4000604@oracle.com>

Seems good.

Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7009346
> 
> 7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
> Reviewed-by:
> 
> The invokespecial method handle adapter attempts to null check its
> argument before the invoke but it's reading the wrong value so it
> occasionally throws a spurious NPE.  The fix is to make it look like
> all the other method handle code that's loading the receiver.  Tested
> with failing test case.
> 

From john.r.rose at oracle.com  Tue Apr 19 19:14:16 2011
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 19 Apr 2011 19:14:16 -0700
Subject: review (XS) for 7009346: java/dyn/InvokeDynamicPrintArgs.java
	fails with NPE on solaris-sparc with -Xcomp
In-Reply-To: <4DAE1C5D.4000604@oracle.com>
References: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>
	<4DAE1C5D.4000604@oracle.com>
Message-ID: <B3869568-E267-4E63-BA6B-D92C1EEC8714@oracle.com>

Yes.  -- John

On Apr 19, 2011, at 4:35 PM, Vladimir Kozlov wrote:

> Seems good.
> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7009346
>> 7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
>> Reviewed-by:
>> The invokespecial method handle adapter attempts to null check its
>> argument before the invoke but it's reading the wrong value so it
>> occasionally throws a spurious NPE.  The fix is to make it look like
>> all the other method handle code that's loading the receiver.  Tested
>> with failing test case.


From christian.thalinger at oracle.com  Wed Apr 20 00:13:08 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 20 Apr 2011 09:13:08 +0200
Subject: review (XS) for 7009346: java/dyn/InvokeDynamicPrintArgs.java
	fails with NPE on solaris-sparc with -Xcomp
In-Reply-To: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>
References: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>
Message-ID: <930DD1D7-4262-4921-BB2E-BD9132D884C1@oracle.com>

On Apr 20, 2011, at 1:31 AM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7009346
> 
> 7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
> Reviewed-by:
> 
> The invokespecial method handle adapter attempts to null check its
> argument before the invoke but it's reading the wrong value so it
> occasionally throws a spurious NPE.  The fix is to make it look like
> all the other method handle code that's loading the receiver.  Tested
> with failing test case.

Ahh, great!  Thanks for spotting that.  -- Christian

From christian.thalinger at oracle.com  Wed Apr 20 08:45:39 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 20 Apr 2011 17:45:39 +0200
Subject: Request for review (S): 6993078: JSR 292 too many pushes: Lesp points
	into register window
Message-ID: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>

http://cr.openjdk.java.net/~twisti/6993078/

6993078: JSR 292 too many pushes:  Lesp points into register window
Reviewed-by:

The logic in InterpreterRuntime::resolve_invokedynamic already handles
the possible race of different threads installing the CallSite object
in the constant pool cache properly.  To short circuit the CallSite
object creation the f1 field in the constant pool cache is checked for
non-null values.

ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
later other fields like flags.  The window between setting f1 and the
flags in one thread makes it possible that another thread already sees
the non-null f1 value but flags is still uninitialized.  That can
result in very strange behaviour since flags encodes the TosState and
the parameter size.

The fix is to set all other values first (currently that's only flags)
and f1 as very last.

The patch also includes some cleanup and additional verify_oop's in
TemplateTable::invokedynamic.

src/cpu/sparc/vm/templateTable_sparc.cpp
src/cpu/x86/vm/templateTable_x86_32.cpp
src/cpu/x86/vm/templateTable_x86_64.cpp
src/share/vm/ci/ciEnv.cpp
src/share/vm/oops/cpCacheOop.cpp
src/share/vm/oops/cpCacheOop.hpp


From vladimir.kozlov at oracle.com  Wed Apr 20 09:03:49 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 20 Apr 2011 09:03:49 -0700
Subject: Request for review (S): 6993078: JSR 292 too many pushes: Lesp
	points into register window
In-Reply-To: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
References: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
Message-ID: <4DAF03E5.1000107@oracle.com>

Looks good.

Vladimir

Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/6993078/
> 
> 6993078: JSR 292 too many pushes:  Lesp points into register window
> Reviewed-by:
> 
> The logic in InterpreterRuntime::resolve_invokedynamic already handles
> the possible race of different threads installing the CallSite object
> in the constant pool cache properly.  To short circuit the CallSite
> object creation the f1 field in the constant pool cache is checked for
> non-null values.
> 
> ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
> later other fields like flags.  The window between setting f1 and the
> flags in one thread makes it possible that another thread already sees
> the non-null f1 value but flags is still uninitialized.  That can
> result in very strange behaviour since flags encodes the TosState and
> the parameter size.
> 
> The fix is to set all other values first (currently that's only flags)
> and f1 as very last.
> 
> The patch also includes some cleanup and additional verify_oop's in
> TemplateTable::invokedynamic.
> 
> src/cpu/sparc/vm/templateTable_sparc.cpp
> src/cpu/x86/vm/templateTable_x86_32.cpp
> src/cpu/x86/vm/templateTable_x86_64.cpp
> src/share/vm/ci/ciEnv.cpp
> src/share/vm/oops/cpCacheOop.cpp
> src/share/vm/oops/cpCacheOop.hpp
> 

From tom.rodriguez at oracle.com  Wed Apr 20 09:12:51 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 20 Apr 2011 09:12:51 -0700
Subject: Request for review (S): 6993078: JSR 292 too many pushes: Lesp
	points into register window
In-Reply-To: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
References: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
Message-ID: <10A8D363-422A-4962-9A7A-B0CBE34CA793@oracle.com>

Why are you using atomic_compare_exchange_oop?  The f1 field should never be compressed.

tom

On Apr 20, 2011, at 8:45 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/6993078/
> 
> 6993078: JSR 292 too many pushes:  Lesp points into register window
> Reviewed-by:
> 
> The logic in InterpreterRuntime::resolve_invokedynamic already handles
> the possible race of different threads installing the CallSite object
> in the constant pool cache properly.  To short circuit the CallSite
> object creation the f1 field in the constant pool cache is checked for
> non-null values.
> 
> ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
> later other fields like flags.  The window between setting f1 and the
> flags in one thread makes it possible that another thread already sees
> the non-null f1 value but flags is still uninitialized.  That can
> result in very strange behaviour since flags encodes the TosState and
> the parameter size.
> 
> The fix is to set all other values first (currently that's only flags)
> and f1 as very last.
> 
> The patch also includes some cleanup and additional verify_oop's in
> TemplateTable::invokedynamic.
> 
> src/cpu/sparc/vm/templateTable_sparc.cpp
> src/cpu/x86/vm/templateTable_x86_32.cpp
> src/cpu/x86/vm/templateTable_x86_64.cpp
> src/share/vm/ci/ciEnv.cpp
> src/share/vm/oops/cpCacheOop.cpp
> src/share/vm/oops/cpCacheOop.hpp
> 


From christian.thalinger at oracle.com  Wed Apr 20 09:48:36 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 20 Apr 2011 18:48:36 +0200
Subject: Request for review (S): 6993078: JSR 292 too many pushes: Lesp
	points into register window
In-Reply-To: <10A8D363-422A-4962-9A7A-B0CBE34CA793@oracle.com>
References: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
	<10A8D363-422A-4962-9A7A-B0CBE34CA793@oracle.com>
Message-ID: <F1D2527A-E02B-41A3-8628-58966A81B3FE@oracle.com>

On Apr 20, 2011, at 6:12 PM, Tom Rodriguez wrote:
> Why are you using atomic_compare_exchange_oop?  The f1 field should never be compressed.

Right, I think I misunderstood something.  webrev is updated.

-- Christian

> 
> tom
> 
> On Apr 20, 2011, at 8:45 AM, Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/6993078/
>> 
>> 6993078: JSR 292 too many pushes:  Lesp points into register window
>> Reviewed-by:
>> 
>> The logic in InterpreterRuntime::resolve_invokedynamic already handles
>> the possible race of different threads installing the CallSite object
>> in the constant pool cache properly.  To short circuit the CallSite
>> object creation the f1 field in the constant pool cache is checked for
>> non-null values.
>> 
>> ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
>> later other fields like flags.  The window between setting f1 and the
>> flags in one thread makes it possible that another thread already sees
>> the non-null f1 value but flags is still uninitialized.  That can
>> result in very strange behaviour since flags encodes the TosState and
>> the parameter size.
>> 
>> The fix is to set all other values first (currently that's only flags)
>> and f1 as very last.
>> 
>> The patch also includes some cleanup and additional verify_oop's in
>> TemplateTable::invokedynamic.
>> 
>> src/cpu/sparc/vm/templateTable_sparc.cpp
>> src/cpu/x86/vm/templateTable_x86_32.cpp
>> src/cpu/x86/vm/templateTable_x86_64.cpp
>> src/share/vm/ci/ciEnv.cpp
>> src/share/vm/oops/cpCacheOop.cpp
>> src/share/vm/oops/cpCacheOop.hpp



From tom.rodriguez at oracle.com  Wed Apr 20 10:10:07 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 20 Apr 2011 10:10:07 -0700
Subject: Request for review (S): 6993078: JSR 292 too many pushes: Lesp
	points into register window
In-Reply-To: <F1D2527A-E02B-41A3-8628-58966A81B3FE@oracle.com>
References: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
	<10A8D363-422A-4962-9A7A-B0CBE34CA793@oracle.com>
	<F1D2527A-E02B-41A3-8628-58966A81B3FE@oracle.com>
Message-ID: <4F1B9667-B019-48A4-9F20-AD3479CF9CC7@oracle.com>

Looks good.

tom

On Apr 20, 2011, at 9:48 AM, Christian Thalinger wrote:

> On Apr 20, 2011, at 6:12 PM, Tom Rodriguez wrote:
>> Why are you using atomic_compare_exchange_oop?  The f1 field should never be compressed.
> 
> Right, I think I misunderstood something.  webrev is updated.
> 
> -- Christian
> 
>> 
>> tom
>> 
>> On Apr 20, 2011, at 8:45 AM, Christian Thalinger wrote:
>> 
>>> http://cr.openjdk.java.net/~twisti/6993078/
>>> 
>>> 6993078: JSR 292 too many pushes:  Lesp points into register window
>>> Reviewed-by:
>>> 
>>> The logic in InterpreterRuntime::resolve_invokedynamic already handles
>>> the possible race of different threads installing the CallSite object
>>> in the constant pool cache properly.  To short circuit the CallSite
>>> object creation the f1 field in the constant pool cache is checked for
>>> non-null values.
>>> 
>>> ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
>>> later other fields like flags.  The window between setting f1 and the
>>> flags in one thread makes it possible that another thread already sees
>>> the non-null f1 value but flags is still uninitialized.  That can
>>> result in very strange behaviour since flags encodes the TosState and
>>> the parameter size.
>>> 
>>> The fix is to set all other values first (currently that's only flags)
>>> and f1 as very last.
>>> 
>>> The patch also includes some cleanup and additional verify_oop's in
>>> TemplateTable::invokedynamic.
>>> 
>>> src/cpu/sparc/vm/templateTable_sparc.cpp
>>> src/cpu/x86/vm/templateTable_x86_32.cpp
>>> src/cpu/x86/vm/templateTable_x86_64.cpp
>>> src/share/vm/ci/ciEnv.cpp
>>> src/share/vm/oops/cpCacheOop.cpp
>>> src/share/vm/oops/cpCacheOop.hpp
> 
> 


From christian.thalinger at oracle.com  Wed Apr 20 10:12:48 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 20 Apr 2011 19:12:48 +0200
Subject: Request for review (S): 6993078: JSR 292 too many pushes: Lesp
	points into register window
In-Reply-To: <4F1B9667-B019-48A4-9F20-AD3479CF9CC7@oracle.com>
References: <0A794DE8-7BCE-4A26-9EEB-2B9D36512CB6@oracle.com>
	<10A8D363-422A-4962-9A7A-B0CBE34CA793@oracle.com>
	<F1D2527A-E02B-41A3-8628-58966A81B3FE@oracle.com>
	<4F1B9667-B019-48A4-9F20-AD3479CF9CC7@oracle.com>
Message-ID: <A394E0B4-FD71-4251-8F94-A743EE625893@oracle.com>

On Apr 20, 2011, at 7:10 PM, Tom Rodriguez wrote:
> Looks good.

Thanks, Tom and Vladimir.  -- Christian

> 
> tom
> 
> On Apr 20, 2011, at 9:48 AM, Christian Thalinger wrote:
> 
>> On Apr 20, 2011, at 6:12 PM, Tom Rodriguez wrote:
>>> Why are you using atomic_compare_exchange_oop?  The f1 field should never be compressed.
>> 
>> Right, I think I misunderstood something.  webrev is updated.
>> 
>> -- Christian
>> 
>>> 
>>> tom
>>> 
>>> On Apr 20, 2011, at 8:45 AM, Christian Thalinger wrote:
>>> 
>>>> http://cr.openjdk.java.net/~twisti/6993078/
>>>> 
>>>> 6993078: JSR 292 too many pushes:  Lesp points into register window
>>>> Reviewed-by:
>>>> 
>>>> The logic in InterpreterRuntime::resolve_invokedynamic already handles
>>>> the possible race of different threads installing the CallSite object
>>>> in the constant pool cache properly.  To short circuit the CallSite
>>>> object creation the f1 field in the constant pool cache is checked for
>>>> non-null values.
>>>> 
>>>> ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
>>>> later other fields like flags.  The window between setting f1 and the
>>>> flags in one thread makes it possible that another thread already sees
>>>> the non-null f1 value but flags is still uninitialized.  That can
>>>> result in very strange behaviour since flags encodes the TosState and
>>>> the parameter size.
>>>> 
>>>> The fix is to set all other values first (currently that's only flags)
>>>> and f1 as very last.
>>>> 
>>>> The patch also includes some cleanup and additional verify_oop's in
>>>> TemplateTable::invokedynamic.
>>>> 
>>>> src/cpu/sparc/vm/templateTable_sparc.cpp
>>>> src/cpu/x86/vm/templateTable_x86_32.cpp
>>>> src/cpu/x86/vm/templateTable_x86_64.cpp
>>>> src/share/vm/ci/ciEnv.cpp
>>>> src/share/vm/oops/cpCacheOop.cpp
>>>> src/share/vm/oops/cpCacheOop.hpp



From vladimir.kozlov at oracle.com  Wed Apr 20 12:11:43 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 20 Apr 2011 12:11:43 -0700
Subject: Request for reviews (S): 7026700: regression in 6u24-rev-b23: Crash
	in C2 compiler in PhaseIdealLoop::build_loop_late_post
Message-ID: <4DAF2FEF.8010308@oracle.com>

This is fix for jdk7.

http://cr.openjdk.java.net/~kvn/7026700/webrev

Fixed 7026700: regression in 6u24-rev-b23: Crash in C2 compiler in 
PhaseIdealLoop::build_loop_late_post

With EA memory slices should be created explicitly for non-static fields 
regardless the value of ReduceFieldZeroing flag. LoadNode::split_through_phi() 
should not check profitability since we want to eliminate loads from 
non-escaping allocations.
I also want to disable memory split verification code in EA until the fix for 
6984348. It produces false negative results since the verification code does not 
cover all cases.

From tom.rodriguez at oracle.com  Wed Apr 20 12:27:48 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 20 Apr 2011 12:27:48 -0700
Subject: Request for reviews (S): 7026700: regression in 6u24-rev-b23:
	Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
In-Reply-To: <4DAF2FEF.8010308@oracle.com>
References: <4DAF2FEF.8010308@oracle.com>
Message-ID: <1C09044A-8BB2-4664-B2D4-5BBE4A4F2422@oracle.com>


On Apr 20, 2011, at 12:11 PM, Vladimir Kozlov wrote:

> This is fix for jdk7.
> 
> http://cr.openjdk.java.net/~kvn/7026700/webrev
> 
> Fixed 7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
> 
> With EA memory slices should be created explicitly for non-static fields regardless the value of ReduceFieldZeroing flag.

Do these really need to guarded?  Couldn't we just always do it?  

> LoadNode::split_through_phi() should not check profitability since we want to eliminate loads from non-escaping allocations.

What about this logic?

  // Skip the split if the region dominates some control edge of the address.
  if (cnt == 3 && !MemNode::all_controls_dominate(address, region))
    return NULL;

Why should we give up when cnt == 3 and not others?

> I also want to disable memory split verification code in EA until the fix for 6984348. It produces false negative results since the verification code does not cover all cases.

Could you normal // comments or use #if 0 instead.  It's should have a comment explaining why it's disabled too.

tom

From tom.rodriguez at oracle.com  Wed Apr 20 13:52:46 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Wed, 20 Apr 2011 20:52:46 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7009346:
	java/dyn/InvokeDynamicPrintArgs.java fails with NPE on
	solaris-sparc with -Xcomp
Message-ID: <20110420205249.D2C9C47C8C@hg.openjdk.java.net>

Changeset: d934e4b931e9
Author:    never
Date:      2011-04-20 09:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d934e4b931e9

7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
Reviewed-by: kvn, jrose, twisti

! src/cpu/sparc/vm/methodHandles_sparc.cpp


From vladimir.kozlov at oracle.com  Wed Apr 20 14:51:18 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 20 Apr 2011 14:51:18 -0700
Subject: Request for reviews (S): 7026700: regression in 6u24-rev-b23:
	Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
In-Reply-To: <1C09044A-8BB2-4664-B2D4-5BBE4A4F2422@oracle.com>
References: <4DAF2FEF.8010308@oracle.com>
	<1C09044A-8BB2-4664-B2D4-5BBE4A4F2422@oracle.com>
Message-ID: <4DAF5556.8000106@oracle.com>

Tom Rodriguez wrote:
> On Apr 20, 2011, at 12:11 PM, Vladimir Kozlov wrote:
> 
>> This is fix for jdk7.
>>
>> http://cr.openjdk.java.net/~kvn/7026700/webrev
>>
>> Fixed 7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
>>
>> With EA memory slices should be created explicitly for non-static fields regardless the value of ReduceFieldZeroing flag.
> 
> Do these really need to guarded?  Couldn't we just always do it?  

Yes, we can do it always. Which makes raw_mem_only parameter obsolete. Should I 
remove it?

> 
>> LoadNode::split_through_phi() should not check profitability since we want to eliminate loads from non-escaping allocations.
> 
> What about this logic?
> 
>   // Skip the split if the region dominates some control edge of the address.
>   if (cnt == 3 && !MemNode::all_controls_dominate(address, region))
>     return NULL;
> 
> Why should we give up when cnt == 3 and not others?

Yes, it is a bug, we should check all cases. I think my intention was to 
restrict the call to expensive all_controls_dominate() only for loops. Fixed.

> 
>> I also want to disable memory split verification code in EA until the fix for 6984348. It produces false negative results since the verification code does not cover all cases.
> 
> Could you normal // comments or use #if 0 instead.  It's should have a comment explaining why it's disabled too.

Done.

I updated webrev.

Thanks,
Vladimir

> 
> tom

From tom.rodriguez at oracle.com  Wed Apr 20 15:03:24 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 20 Apr 2011 15:03:24 -0700
Subject: Request for reviews (S): 7026700: regression in 6u24-rev-b23:
	Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
In-Reply-To: <4DAF5556.8000106@oracle.com>
References: <4DAF2FEF.8010308@oracle.com>
	<1C09044A-8BB2-4664-B2D4-5BBE4A4F2422@oracle.com>
	<4DAF5556.8000106@oracle.com>
Message-ID: <7BA5DA05-BA78-4218-A524-B397BD912F76@oracle.com>


On Apr 20, 2011, at 2:51 PM, Vladimir Kozlov wrote:

> Tom Rodriguez wrote:
>> On Apr 20, 2011, at 12:11 PM, Vladimir Kozlov wrote:
>>> This is fix for jdk7.
>>> 
>>> http://cr.openjdk.java.net/~kvn/7026700/webrev
>>> 
>>> Fixed 7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
>>> 
>>> With EA memory slices should be created explicitly for non-static fields regardless the value of ReduceFieldZeroing flag.
>> Do these really need to guarded?  Couldn't we just always do it?  
> 
> Yes, we can do it always. Which makes raw_mem_only parameter obsolete. Should I remove it?

Sure.  The comment for raw_mem_only is incorrect anyway.

> 
>>> LoadNode::split_through_phi() should not check profitability since we want to eliminate loads from non-escaping allocations.
>> What about this logic?
>>  // Skip the split if the region dominates some control edge of the address.
>>  if (cnt == 3 && !MemNode::all_controls_dominate(address, region))
>>    return NULL;
>> Why should we give up when cnt == 3 and not others?
> 
> Yes, it is a bug, we should check all cases. I think my intention was to restrict the call to expensive all_controls_dominate() only for loops. Fixed.
> 
>>> I also want to disable memory split verification code in EA until the fix for 6984348. It produces false negative results since the verification code does not cover all cases.
>> Could you normal // comments or use #if 0 instead.  It's should have a comment explaining why it's disabled too.
> 
> Done.
> 
> I updated webrev.

Looks good.

tom

> 
> Thanks,
> Vladimir
> 
>> tom


From vladimir.kozlov at oracle.com  Wed Apr 20 15:56:58 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 20 Apr 2011 15:56:58 -0700
Subject: Request for reviews (S): 7026700: regression in 6u24-rev-b23:
	Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
In-Reply-To: <7BA5DA05-BA78-4218-A524-B397BD912F76@oracle.com>
References: <4DAF2FEF.8010308@oracle.com>
	<1C09044A-8BB2-4664-B2D4-5BBE4A4F2422@oracle.com>
	<4DAF5556.8000106@oracle.com>
	<7BA5DA05-BA78-4218-A524-B397BD912F76@oracle.com>
Message-ID: <4DAF64BA.7010107@oracle.com>

Thank you, Tom

Vladimir

Tom Rodriguez wrote:
> On Apr 20, 2011, at 2:51 PM, Vladimir Kozlov wrote:
> 
>> Tom Rodriguez wrote:
>>> On Apr 20, 2011, at 12:11 PM, Vladimir Kozlov wrote:
>>>> This is fix for jdk7.
>>>>
>>>> http://cr.openjdk.java.net/~kvn/7026700/webrev
>>>>
>>>> Fixed 7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
>>>>
>>>> With EA memory slices should be created explicitly for non-static fields regardless the value of ReduceFieldZeroing flag.
>>> Do these really need to guarded?  Couldn't we just always do it?  
>> Yes, we can do it always. Which makes raw_mem_only parameter obsolete. Should I remove it?
> 
> Sure.  The comment for raw_mem_only is incorrect anyway.
> 
>>>> LoadNode::split_through_phi() should not check profitability since we want to eliminate loads from non-escaping allocations.
>>> What about this logic?
>>>  // Skip the split if the region dominates some control edge of the address.
>>>  if (cnt == 3 && !MemNode::all_controls_dominate(address, region))
>>>    return NULL;
>>> Why should we give up when cnt == 3 and not others?
>> Yes, it is a bug, we should check all cases. I think my intention was to restrict the call to expensive all_controls_dominate() only for loops. Fixed.
>>
>>>> I also want to disable memory split verification code in EA until the fix for 6984348. It produces false negative results since the verification code does not cover all cases.
>>> Could you normal // comments or use #if 0 instead.  It's should have a comment explaining why it's disabled too.
>> Done.
>>
>> I updated webrev.
> 
> Looks good.
> 
> tom
> 
>> Thanks,
>> Vladimir
>>
>>> tom
> 

From tom.rodriguez at oracle.com  Wed Apr 20 17:04:07 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 20 Apr 2011 17:04:07 -0700
Subject: review (XS) for 7009346: java/dyn/InvokeDynamicPrintArgs.java
	fails with NPE on solaris-sparc with -Xcomp
In-Reply-To: <930DD1D7-4262-4921-BB2E-BD9132D884C1@oracle.com>
References: <8B035EBB-055C-4311-8F3A-C492F3A2BB72@oracle.com>
	<930DD1D7-4262-4921-BB2E-BD9132D884C1@oracle.com>
Message-ID: <C3C5FCA2-506F-4BA2-B3F3-CABACCE9884B@oracle.com>

Thanks!

tom

On Apr 20, 2011, at 12:13 AM, Christian Thalinger wrote:

> On Apr 20, 2011, at 1:31 AM, Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7009346
>> 
>> 7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
>> Reviewed-by:
>> 
>> The invokespecial method handle adapter attempts to null check its
>> argument before the invoke but it's reading the wrong value so it
>> occasionally throws a spurious NPE.  The fix is to make it look like
>> all the other method handle code that's loading the receiver.  Tested
>> with failing test case.
> 
> Ahh, great!  Thanks for spotting that.  -- Christian


From vladimir.kozlov at oracle.com  Thu Apr 21 00:03:59 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Thu, 21 Apr 2011 07:03:59 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7026700: regression in 6u24-rev-b23:
	Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
Message-ID: <20110421070407.41D1F47D04@hg.openjdk.java.net>

Changeset: 66b0e2371912
Author:    kvn
Date:      2011-04-20 18:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/66b0e2371912

7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
Summary: memory slices should be always created for non-static fields after allocation
Reviewed-by: never

! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp


From christian.thalinger at oracle.com  Thu Apr 21 09:00:58 2011
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Thu, 21 Apr 2011 16:00:58 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 6993078: JSR 292 too many pushes: Lesp
	points into register window
Message-ID: <20110421160104.CF88E47D47@hg.openjdk.java.net>

Changeset: 08ccee2c4dbf
Author:    twisti
Date:      2011-04-21 00:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/08ccee2c4dbf

6993078: JSR 292 too many pushes:  Lesp points into register window
Reviewed-by: kvn, never

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/oops/cpCacheOop.cpp


From tom.rodriguez at oracle.com  Thu Apr 21 13:47:57 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 21 Apr 2011 13:47:57 -0700
Subject: review (S) for 7030715: JSR 292 JRuby
	test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
Message-ID: <86E4AFC9-97FE-4BEB-B00A-1B8A65F8E508@oracle.com>

http://cr.openjdk.java.net/~never/7030715

7030715: JSR 292 JRuby test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
Reviewed-by:

is_static shouldn't be called on unloaded ciMethods.  Instead of just
adjusting the assert I decided to move the proper logic into ciMethod
and modify the regular arg_size routine to complain if it's called on
unloaded methods since it may return the wrong answer in that case.
Tested with failing test and with CTW to ensure that the new assert
doesn't trigger for other code.


From john.cuthbertson at oracle.com  Fri Apr 22 17:28:01 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 22 Apr 2011 17:28:01 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
Message-ID: <4DB21D11.5090308@oracle.com>

Hi Everyone,

Can I have a couple of volunteers to look over these changes? The webrev 
can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.1

The issue here was very similar to the issue that caused 6789220 - the 
difference here was that the reference handler was blocked while waiting 
for the MethodCompileQueue_lock rather than waiting on a blocking 
compilation. To summarize:

Thread 6 (reference handler thread), while owning the pending list lock, 
requested a compilation and was blocked waiting on the 
MethodCompileQueue_lock.

Thread 11 (compiler thread 1), while owning the Compile_lock, attempted 
to allocate a Class mirror which triggered GC. In the GC it was blocked 
attempting to lock the pending list lock.

Thread 12 (compiler thread 2) was registering a compiled method and, 
while owning the MethodCompileQueue_lock, was blocked waiting on the 
Compile_lock.

The solution is to make the reference handler thread not block while 
holding the pending list lock. If the requesting thread is the reference 
handler thread, then an attempt is made to lock the 
MethodCompileQueue_lock in CompileBroker::compile_method_base and, if 
that is unsuccessful, we just return with enqueueing the compile task. 
Otherwise a regular blocking lock attempt is made. I also tweaked the 
fix made by Bengt for 6789220 to make all compilation requests by the 
reference handler thread non-blocking.

Testing: the failing test case has been running successfully on the 
VMSQE machine for 2 days (normally I see the deadlock after 20 minutes 
or so); the nsk tests; and a jprt job is the queue.

Thanks,

JohnC


From john.cuthbertson at oracle.com  Fri Apr 22 17:38:23 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 22 Apr 2011 17:38:23 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <4DB21D11.5090308@oracle.com>
References: <4DB21D11.5090308@oracle.com>
Message-ID: <4DB21F7F.9050308@oracle.com>

Hi EVeryone.

Typo....

On 04/22/11 17:28, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers to look over these changes? The 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>
> The issue here was very similar to the issue that caused 6789220 - the 
> difference here was that the reference handler was blocked while 
> waiting for the MethodCompileQueue_lock rather than waiting on a 
> blocking compilation. To summarize:
>
> Thread 6 (reference handler thread), while owning the pending list 
> lock, requested a compilation and was blocked waiting on the 
> MethodCompileQueue_lock.
>
> Thread 11 (compiler thread 1), while owning the Compile_lock, 
> attempted to allocate a Class mirror which triggered GC. In the GC it 
> was blocked attempting to lock the pending list lock.
>
> Thread 12 (compiler thread 2) was registering a compiled method and, 
> while owning the MethodCompileQueue_lock, was blocked waiting on the 
> Compile_lock.
>
> The solution is to make the reference handler thread not block while 
> holding the pending list lock. If the requesting thread is the 
> reference handler thread, then an attempt is made to lock the 
> MethodCompileQueue_lock in CompileBroker::compile_method_base and, if 
> that is unsuccessful, we just return with enqueueing the compile task. 
> Otherwise a regular blocking lock attempt is made. I also tweaked the 
> fix made by Bengt for 6789220 to make all compilation requests by the 
> reference handler thread non-blocking.
The above paragraph should read;

The solution is to make the reference handler thread not block while 
holding the pending list lock. If the requesting thread is the reference 
handler thread, then an attempt is made to lock the 
MethodCompileQueue_lock in CompileBroker::compile_method_base and, if 
that is unsuccessful, we just return _without_ enqueueing the 
compilation request. Otherwise a regular blocking lock attempt is made. 
I also tweaked the fix made by Bengt for 6789220 to make all compilation 
requests by the reference handler thread non-blocking.
>
> Testing: the failing test case has been running successfully on the 
> VMSQE machine for 2 days (normally I see the deadlock after 20 minutes 
> or so); the nsk tests; and a jprt job is the queue.
>
> Thanks,
>
> JohnC
>


From tom.rodriguez at oracle.com  Fri Apr 22 18:48:55 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 22 Apr 2011 18:48:55 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <4DB21F7F.9050308@oracle.com>
References: <4DB21D11.5090308@oracle.com> <4DB21F7F.9050308@oracle.com>
Message-ID: <28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>

Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead?  That seems more robust and targeted.   Something like:

if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
  return false;
}

replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.

tom

On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:

> Hi EVeryone.
> 
> Typo....
> 
> On 04/22/11 17:28, John Cuthbertson wrote:
>> Hi Everyone,
>> 
>> Can I have a couple of volunteers to look over these changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>> 
>> The issue here was very similar to the issue that caused 6789220 - the difference here was that the reference handler was blocked while waiting for the MethodCompileQueue_lock rather than waiting on a blocking compilation. To summarize:
>> 
>> Thread 6 (reference handler thread), while owning the pending list lock, requested a compilation and was blocked waiting on the MethodCompileQueue_lock.
>> 
>> Thread 11 (compiler thread 1), while owning the Compile_lock, attempted to allocate a Class mirror which triggered GC. In the GC it was blocked attempting to lock the pending list lock.
>> 
>> Thread 12 (compiler thread 2) was registering a compiled method and, while owning the MethodCompileQueue_lock, was blocked waiting on the Compile_lock.
>> 
>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return with enqueueing the compile task. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
> The above paragraph should read;
> 
> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return _without_ enqueueing the compilation request. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>> 
>> Testing: the failing test case has been running successfully on the VMSQE machine for 2 days (normally I see the deadlock after 20 minutes or so); the nsk tests; and a jprt job is the queue.
>> 
>> Thanks,
>> 
>> JohnC
>> 
> 


From john.cuthbertson at oracle.com  Mon Apr 25 16:37:15 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 25 Apr 2011 16:37:15 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>
References: <4DB21D11.5090308@oracle.com> <4DB21F7F.9050308@oracle.com>
	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>
Message-ID: <4DB605AB.7080201@oracle.com>

Hi Everyone,

A new webrev that is essentially Tom's suggestion can be found at: 
http://cr.openjdk.java.net/~johnc/7037756/webrev.2/. I also reverted 
Bengt's fix for 6789220 as, with Tom's suggested fix, a thread that owns 
the pending list will no longer be blocked in 
CompileBroker::compile_method_base.

Testing: Ran over the weekend with the test case for 7037756; the test 
case for 6789220 (which fails 50% of the time with Bengt's fix removed); 
nsk tests; jprt.

Thanks,

JohnC


On 04/22/11 18:48, Tom Rodriguez wrote:
> Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead?  That seems more robust and targeted.   Something like:
>
> if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
>   return false;
> }
>
> replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.
>
> tom
>
> On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:
>
>   
>> Hi EVeryone.
>>
>> Typo....
>>
>> On 04/22/11 17:28, John Cuthbertson wrote:
>>     
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers to look over these changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>>>
>>> The issue here was very similar to the issue that caused 6789220 - the difference here was that the reference handler was blocked while waiting for the MethodCompileQueue_lock rather than waiting on a blocking compilation. To summarize:
>>>
>>> Thread 6 (reference handler thread), while owning the pending list lock, requested a compilation and was blocked waiting on the MethodCompileQueue_lock.
>>>
>>> Thread 11 (compiler thread 1), while owning the Compile_lock, attempted to allocate a Class mirror which triggered GC. In the GC it was blocked attempting to lock the pending list lock.
>>>
>>> Thread 12 (compiler thread 2) was registering a compiled method and, while owning the MethodCompileQueue_lock, was blocked waiting on the Compile_lock.
>>>
>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return with enqueueing the compile task. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>       
>> The above paragraph should read;
>>
>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return _without_ enqueueing the compilation request. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>     
>>> Testing: the failing test case has been running successfully on the VMSQE machine for 2 days (normally I see the deadlock after 20 minutes or so); the nsk tests; and a jprt job is the queue.
>>>
>>> Thanks,
>>>
>>> JohnC
>>>
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110425/1cd74897/attachment.html 

From tom.rodriguez at oracle.com  Mon Apr 25 17:12:45 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 25 Apr 2011 17:12:45 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <4DB605AB.7080201@oracle.com>
References: <4DB21D11.5090308@oracle.com> <4DB21F7F.9050308@oracle.com>
	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>
	<4DB605AB.7080201@oracle.com>
Message-ID: <41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>

Seems ok.  We'll never compile the main loop of the reference handler thread new but that doesn't seem like it should matter much.

tom

On Apr 25, 2011, at 4:37 PM, John Cuthbertson wrote:

> Hi Everyone,
> 
> A new webrev that is essentially Tom's suggestion can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.2/. I also reverted Bengt's fix for 6789220 as, with Tom's suggested fix, a thread that owns the pending list will no longer be blocked in CompileBroker::compile_method_base.
> 
> Testing: Ran over the weekend with the test case for 7037756; the test case for 6789220 (which fails 50% of the time with Bengt's fix removed); nsk tests; jprt.
> 
> Thanks,
> 
> JohnC
> 
> 
> On 04/22/11 18:48, Tom Rodriguez wrote:
>> Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead?  That seems more robust and targeted.   Something like:
>> 
>> if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
>>   return false;
>> }
>> 
>> replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.
>> 
>> tom
>> 
>> On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:
>> 
>>   
>> 
>>> Hi EVeryone.
>>> 
>>> Typo....
>>> 
>>> On 04/22/11 17:28, John Cuthbertson wrote:
>>>     
>>> 
>>>> Hi Everyone,
>>>> 
>>>> Can I have a couple of volunteers to look over these changes? The webrev can be found at: 
>>>> http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>>>> 
>>>> 
>>>> The issue here was very similar to the issue that caused 6789220 - the difference here was that the reference handler was blocked while waiting for the MethodCompileQueue_lock rather than waiting on a blocking compilation. To summarize:
>>>> 
>>>> Thread 6 (reference handler thread), while owning the pending list lock, requested a compilation and was blocked waiting on the MethodCompileQueue_lock.
>>>> 
>>>> Thread 11 (compiler thread 1), while owning the Compile_lock, attempted to allocate a Class mirror which triggered GC. In the GC it was blocked attempting to lock the pending list lock.
>>>> 
>>>> Thread 12 (compiler thread 2) was registering a compiled method and, while owning the MethodCompileQueue_lock, was blocked waiting on the Compile_lock.
>>>> 
>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return with enqueueing the compile task. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>       
>>>> 
>>> The above paragraph should read;
>>> 
>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return _without_ enqueueing the compilation request. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>     
>>> 
>>>> Testing: the failing test case has been running successfully on the VMSQE machine for 2 days (normally I see the deadlock after 20 minutes or so); the nsk tests; and a jprt job is the queue.
>>>> 
>>>> Thanks,
>>>> 
>>>> JohnC
>>>> 
>>>>       
>>>> 
>> 
>>   
>> 
> 


From john.cuthbertson at oracle.com  Mon Apr 25 17:56:05 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 25 Apr 2011 17:56:05 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
References: <4DB21D11.5090308@oracle.com> <4DB21F7F.9050308@oracle.com>
	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>
	<4DB605AB.7080201@oracle.com>
	<41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
Message-ID: <4DB61825.4040101@oracle.com>

Hi Tom,

Thanks for the review and suggestion. Earlier I instrumented the compile 
tasks to record and display the requesting thread. In the test case (a 
jck test suite) I only saw 4 or 5 compilation requests coming from the 
reference handler thread. If it becomes performance critical then I 
guess a variant can be resurrected - though I prefer the simpler code.

Thanks again.

JohnC

On 04/25/11 17:12, Tom Rodriguez wrote:
> Seems ok.  We'll never compile the main loop of the reference handler thread new but that doesn't seem like it should matter much.
>
> tom
>
> On Apr 25, 2011, at 4:37 PM, John Cuthbertson wrote:
>
>   
>> Hi Everyone,
>>
>> A new webrev that is essentially Tom's suggestion can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.2/. I also reverted Bengt's fix for 6789220 as, with Tom's suggested fix, a thread that owns the pending list will no longer be blocked in CompileBroker::compile_method_base.
>>
>> Testing: Ran over the weekend with the test case for 7037756; the test case for 6789220 (which fails 50% of the time with Bengt's fix removed); nsk tests; jprt.
>>
>> Thanks,
>>
>> JohnC
>>
>>
>> On 04/22/11 18:48, Tom Rodriguez wrote:
>>     
>>> Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead?  That seems more robust and targeted.   Something like:
>>>
>>> if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
>>>   return false;
>>> }
>>>
>>> replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.
>>>
>>> tom
>>>
>>> On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:
>>>
>>>   
>>>
>>>       
>>>> Hi EVeryone.
>>>>
>>>> Typo....
>>>>
>>>> On 04/22/11 17:28, John Cuthbertson wrote:
>>>>     
>>>>
>>>>         
>>>>> Hi Everyone,
>>>>>
>>>>> Can I have a couple of volunteers to look over these changes? The webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>>>>>
>>>>>
>>>>> The issue here was very similar to the issue that caused 6789220 - the difference here was that the reference handler was blocked while waiting for the MethodCompileQueue_lock rather than waiting on a blocking compilation. To summarize:
>>>>>
>>>>> Thread 6 (reference handler thread), while owning the pending list lock, requested a compilation and was blocked waiting on the MethodCompileQueue_lock.
>>>>>
>>>>> Thread 11 (compiler thread 1), while owning the Compile_lock, attempted to allocate a Class mirror which triggered GC. In the GC it was blocked attempting to lock the pending list lock.
>>>>>
>>>>> Thread 12 (compiler thread 2) was registering a compiled method and, while owning the MethodCompileQueue_lock, was blocked waiting on the Compile_lock.
>>>>>
>>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return with enqueueing the compile task. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>>       
>>>>>
>>>>>           
>>>> The above paragraph should read;
>>>>
>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return _without_ enqueueing the compilation request. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>     
>>>>
>>>>         
>>>>> Testing: the failing test case has been running successfully on the VMSQE machine for 2 days (normally I see the deadlock after 20 minutes or so); the nsk tests; and a jprt job is the queue.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JohnC
>>>>>
>>>>>       
>>>>>
>>>>>           
>>>   
>>>
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110425/303f24c9/attachment.html 

From tom.rodriguez at oracle.com  Mon Apr 25 18:31:58 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Tue, 26 Apr 2011 01:31:58 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7030715: JSR 292 JRuby
	test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
Message-ID: <20110426013205.C7AE147FD2@hg.openjdk.java.net>

Changeset: 548597e74aa4
Author:    never
Date:      2011-04-25 16:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/548597e74aa4

7030715: JSR 292 JRuby test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
Reviewed-by: twisti

! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/opto/graphKit.cpp


From y.s.ramakrishna at oracle.com  Mon Apr 25 19:20:47 2011
From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna)
Date: Mon, 25 Apr 2011 19:20:47 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
References: <4DB21D11.5090308@oracle.com>
	<4DB21F7F.9050308@oracle.com>	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>	<4DB605AB.7080201@oracle.com>
	<41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
Message-ID: <4DB62BFF.1030503@oracle.com>

On 4/25/2011 5:12 PM, Tom Rodriguez wrote:
> Seems ok.  We'll never compile the main loop of the reference handler thread new but that doesn't seem like it should matter much.

May be test with a benchmark that stresses Reference object handling.
May be the bottleneck will still not be the reference handler thread
running interpreted code, but worth checking (may be later).

Can the compiler thread be prevented from trying to allocate
in the heap while holding the Compile_lock? (Would it work
for it to drop and reacquire the lock around such allocations,
or is that not feasible? Just doing some loud thinking.)

(Or could one safely pre-compile the reference handler's code
before start-up so it doesn't always run interpreted?)

-- ramki

>
> tom
>
> On Apr 25, 2011, at 4:37 PM, John Cuthbertson wrote:
>
>> Hi Everyone,
>>
>> A new webrev that is essentially Tom's suggestion can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.2/. I also reverted Bengt's fix for 6789220 as, with Tom's suggested fix, a thread that owns the pending list will no longer be blocked in CompileBroker::compile_method_base.
>>
>> Testing: Ran over the weekend with the test case for 7037756; the test case for 6789220 (which fails 50% of the time with Bengt's fix removed); nsk tests; jprt.
>>
>> Thanks,
>>
>> JohnC
>>
>>
>> On 04/22/11 18:48, Tom Rodriguez wrote:
>>> Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead?  That seems more robust and targeted.   Something like:
>>>
>>> if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
>>>    return false;
>>> }
>>>
>>> replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.
>>>
>>> tom
>>>
>>> On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:
>>>
>>>
>>>
>>>> Hi EVeryone.
>>>>
>>>> Typo....
>>>>
>>>> On 04/22/11 17:28, John Cuthbertson wrote:
>>>>
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> Can I have a couple of volunteers to look over these changes? The webrev can be found at:
>>>>> http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>>>>>
>>>>>
>>>>> The issue here was very similar to the issue that caused 6789220 - the difference here was that the reference handler was blocked while waiting for the MethodCompileQueue_lock rather than waiting on a blocking compilation. To summarize:
>>>>>
>>>>> Thread 6 (reference handler thread), while owning the pending list lock, requested a compilation and was blocked waiting on the MethodCompileQueue_lock.
>>>>>
>>>>> Thread 11 (compiler thread 1), while owning the Compile_lock, attempted to allocate a Class mirror which triggered GC. In the GC it was blocked attempting to lock the pending list lock.
>>>>>
>>>>> Thread 12 (compiler thread 2) was registering a compiled method and, while owning the MethodCompileQueue_lock, was blocked waiting on the Compile_lock.
>>>>>
>>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return with enqueueing the compile task. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>>
>>>>>
>>>> The above paragraph should read;
>>>>
>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return _without_ enqueueing the compilation request. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>
>>>>
>>>>> Testing: the failing test case has been running successfully on the VMSQE machine for 2 days (normally I see the deadlock after 20 minutes or so); the nsk tests; and a jprt job is the queue.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JohnC
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>


From tom.rodriguez at oracle.com  Mon Apr 25 19:58:20 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 25 Apr 2011 19:58:20 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <4DB62BFF.1030503@oracle.com>
References: <4DB21D11.5090308@oracle.com>
	<4DB21F7F.9050308@oracle.com>	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>	<4DB605AB.7080201@oracle.com>
	<41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
	<4DB62BFF.1030503@oracle.com>
Message-ID: <401F8218-C523-4063-9F74-85F1F4AB536A@oracle.com>


On Apr 25, 2011, at 7:20 PM, Y. Srinivas Ramakrishna wrote:

> On 4/25/2011 5:12 PM, Tom Rodriguez wrote:
>> Seems ok.  We'll never compile the main loop of the reference handler thread new but that doesn't seem like it should matter much.
> 
> May be test with a benchmark that stresses Reference object handling.
> May be the bottleneck will still not be the reference handler thread
> running interpreted code, but worth checking (may be later).
> 
> Can the compiler thread be prevented from trying to allocate
> in the heap while holding the Compile_lock? (Would it work
> for it to drop and reacquire the lock around such allocations,
> or is that not feasible? Just doing some loud thinking.)

Well the compiler itself isn't acquiring the Compile_lock.  It appears to be this code in objArrayKlassKlass.

        KlassHandle ek;
        {
          MutexUnlocker mu(MultiArray_lock);
          MutexUnlocker mc(Compile_lock);   // for vtables                                                                                  
          klassOop sk = element_super->array_klass(CHECK_0);
          super_klass = KlassHandle(THREAD, sk);
          for( int i = element_supers->length()-1; i >= 0; i-- ) {
            KlassHandle elem_super (THREAD, element_supers->obj_at(i));
            elem_super->array_klass(CHECK_0);
          }
          // Now retry from the beginning                                                                                                    
          klassOop klass_oop = element_klass->array_klass(n, CHECK_0);
          // Create a handle because the enclosing brace, when locking                                                                      
          // can cause a gc.  Better to have this function return a Handle.                                                                  
          ek = KlassHandle(THREAD, klass_oop);
        }  // re-lock                                                                                                                        
        return ek();

I really don't understand the usage of Compile_lock here or the comment "for vtables".  All the array klasses do something similar and I don't get it.  The main purpose of Compile_lock is control updates to the system dictionary but I don't see why the array klasses have to do anything special here.

> 
> (Or could one safely pre-compile the reference handler's code
> before start-up so it doesn't always run interpreted?)

We could have a small side queue that we could enqueue these on and when a later safe request comes in we can request a non blocking compile of them.  It's kind of gross but it would work I think.  It could even just be a queue of length one instead of a full data structure.

tom

> 
> -- ramki
> 
>> 
>> tom
>> 
>> On Apr 25, 2011, at 4:37 PM, John Cuthbertson wrote:
>> 
>>> Hi Everyone,
>>> 
>>> A new webrev that is essentially Tom's suggestion can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.2/. I also reverted Bengt's fix for 6789220 as, with Tom's suggested fix, a thread that owns the pending list will no longer be blocked in CompileBroker::compile_method_base.
>>> 
>>> Testing: Ran over the weekend with the test case for 7037756; the test case for 6789220 (which fails 50% of the time with Bengt's fix removed); nsk tests; jprt.
>>> 
>>> Thanks,
>>> 
>>> JohnC
>>> 
>>> 
>>> On 04/22/11 18:48, Tom Rodriguez wrote:
>>>> Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead?  That seems more robust and targeted.   Something like:
>>>> 
>>>> if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
>>>>   return false;
>>>> }
>>>> 
>>>> replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.
>>>> 
>>>> tom
>>>> 
>>>> On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:
>>>> 
>>>> 
>>>> 
>>>>> Hi EVeryone.
>>>>> 
>>>>> Typo....
>>>>> 
>>>>> On 04/22/11 17:28, John Cuthbertson wrote:
>>>>> 
>>>>> 
>>>>>> Hi Everyone,
>>>>>> 
>>>>>> Can I have a couple of volunteers to look over these changes? The webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~johnc/7037756/webrev.1
>>>>>> 
>>>>>> 
>>>>>> The issue here was very similar to the issue that caused 6789220 - the difference here was that the reference handler was blocked while waiting for the MethodCompileQueue_lock rather than waiting on a blocking compilation. To summarize:
>>>>>> 
>>>>>> Thread 6 (reference handler thread), while owning the pending list lock, requested a compilation and was blocked waiting on the MethodCompileQueue_lock.
>>>>>> 
>>>>>> Thread 11 (compiler thread 1), while owning the Compile_lock, attempted to allocate a Class mirror which triggered GC. In the GC it was blocked attempting to lock the pending list lock.
>>>>>> 
>>>>>> Thread 12 (compiler thread 2) was registering a compiled method and, while owning the MethodCompileQueue_lock, was blocked waiting on the Compile_lock.
>>>>>> 
>>>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return with enqueueing the compile task. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>>> 
>>>>>> 
>>>>> The above paragraph should read;
>>>>> 
>>>>> The solution is to make the reference handler thread not block while holding the pending list lock. If the requesting thread is the reference handler thread, then an attempt is made to lock the MethodCompileQueue_lock in CompileBroker::compile_method_base and, if that is unsuccessful, we just return _without_ enqueueing the compilation request. Otherwise a regular blocking lock attempt is made. I also tweaked the fix made by Bengt for 6789220 to make all compilation requests by the reference handler thread non-blocking.
>>>>> 
>>>>> 
>>>>>> Testing: the failing test case has been running successfully on the VMSQE machine for 2 days (normally I see the deadlock after 20 minutes or so); the nsk tests; and a jprt job is the queue.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> JohnC
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 


From john.cuthbertson at oracle.com  Tue Apr 26 10:55:11 2011
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 26 Apr 2011 10:55:11 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <401F8218-C523-4063-9F74-85F1F4AB536A@oracle.com>
References: <4DB21D11.5090308@oracle.com>
	<4DB21F7F.9050308@oracle.com>	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>	<4DB605AB.7080201@oracle.com>
	<41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
	<4DB62BFF.1030503@oracle.com>
	<401F8218-C523-4063-9F74-85F1F4AB536A@oracle.com>
Message-ID: <4DB706FF.9050701@oracle.com>

Hi Tom, Rmki,

I think that the main loop might still get compiled (some of the time) 
even with this fix. Here's the code of the run method:

        public void run() {
            for (;;) {

                Reference r;
                synchronized (lock) {
                    if (pending != null) {
                        r = pending;
                        Reference rn = r.next;
                        pending = (rn == r) ? null : rn;
                        r.next = r;
                    } else {
                        try {
                            lock.wait();
                        } catch (InterruptedException x) { }
                        continue;
                    }
                }

                // Fast path for cleaners
                if (r instanceof Cleaner) {
                    ((Cleaner)r).clean();
                    continue;
                }

                ReferenceQueue q = r.queue;
                if (q != ReferenceQueue.NULL) q.enqueue(r);
            }
        }

With Xcomp, the reference handler thread is not holding the lock when 
run() is called and so the compilation request would be successful. 
Normally though the compilation of run() would be an OSR compilation - 
it looks like there are 3 backward branches and only one of which is 
inside the the locked region. If we have a lot of references to enqueue 
then I would expect that the backward branch after the enqueue() call 
would trigger an OSR compile (I don't think the branch inside the locked 
region would be executed any more frequently).

The actual method I saw being compiled while holding the pending list 
lock was: 
java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference;

Other methods invoked from the locked region are:

java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference;
java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;
java/lang/Object.wait:()V

Of these 
java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; is 
also invoked outside of the locked region (it's actually at bci:0 - 
which is the target bci of the backward branches), and 
java/lang/Object.wait:()V is a native method.


On 04/25/11 19:58, Tom Rodriguez wrote:
>
> We could have a small side queue that we could enqueue these on and when a later safe request comes in we can request a non blocking compile of them.  It's kind of gross but it would work I think.  It could even just be a queue of length one instead of a full data structure.
>
> tom
>
>   
I think having a special queue for these is a lot uglier than adapting 
the original fix (i.e. the one with the try_lock) to use ownership of 
the pending list lock rather than the thread id.

JohnC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110426/54b165a3/attachment.html 

From vladimir.kozlov at oracle.com  Tue Apr 26 11:14:02 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 26 Apr 2011 11:14:02 -0700
Subject: Request for reviews (XS): 7039586:
	test/java/util/Collections/Rotate.java failing with hs21-b09
Message-ID: <4DB70B6A.9080209@oracle.com>

http://cr.openjdk.java.net/~kvn/7039586/webrev

Fixed 7039586: test/java/util/Collections/Rotate.java failing with hs21-b09

A predicate should not be moved in partial peel optimization since it will 
invalidate jvm state of its uncommon trap.
I looked on other places where a predicate is cloned and moved and they seems fine.

From tom.rodriguez at oracle.com  Tue Apr 26 11:31:12 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 26 Apr 2011 11:31:12 -0700
Subject: RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220
In-Reply-To: <4DB706FF.9050701@oracle.com>
References: <4DB21D11.5090308@oracle.com>
	<4DB21F7F.9050308@oracle.com>	<28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com>	<4DB605AB.7080201@oracle.com>
	<41B43E13-9FE0-41CF-BA2B-865AEE65A1A1@oracle.com>
	<4DB62BFF.1030503@oracle.com>
	<401F8218-C523-4063-9F74-85F1F4AB536A@oracle.com>
	<4DB706FF.9050701@oracle.com>
Message-ID: <9EF575D0-A5C9-407A-8896-2625A763B379@oracle.com>

I'm not against a hybrid of your original fix and the current one.  Use the owns_pending_list_lock check instead of the is_reference_handler_check and keep the rest.  The try/lock logic itself it fairly ugly though.  Maybe it's just the name LockerMutexLocker that seems wrong.  Maybe LockedMutexUnlocker or a variant constructor for MutexLocker like this:

  MutexLocker(Monitor * mutex, bool already_locked) {
    assert(mutex->rank() != Mutex::special,
      "Special ranked mutex should only use MutexLockerEx");
    _mutex = mutex;
    if (already_locked) {
      assert(mutex->owned_by_self(), "must already be locked");
    } else {
      _mutex->lock();
    }
  }

Then the try_lock piece just sets a flag that we pass into that and otherwise the locking proceeds as normal.

tom

On Apr 26, 2011, at 10:55 AM, John Cuthbertson wrote:

> Hi Tom, Rmki,
> 
> I think that the main loop might still get compiled (some of the time) even with this fix. Here's the code of the run method:
> 
>         public void run() {
>             for (;;) {
> 
>                 Reference r;
>                 synchronized (lock) {
>                     if (pending != null) {
>                         r = pending;
>                         Reference rn = r.next;
>                         pending = (rn == r) ? null : rn;
>                         r.next = r;
>                     } else {
>                         try {
>                             lock.wait();
>                         } catch (InterruptedException x) { }
>                         continue;
>                     }
>                 }
> 
>                 // Fast path for cleaners
>                 if (r instanceof Cleaner) {
>                     ((Cleaner)r).clean();
>                     continue;
>                 }
> 
>                 ReferenceQueue q = r.queue;
>                 if (q != ReferenceQueue.NULL) q.enqueue(r);
>             }
>         }
> 
> With Xcomp, the reference handler thread is not holding the lock when run() is called and so the compilation request would be successful. Normally though the compilation of run() would be an OSR compilation - it looks like there are 3 backward branches and only one of which is inside the the locked region. If we have a lot of references to enqueue then I would expect that the backward branch after the enqueue() call would trigger an OSR compile (I don't think the branch inside the locked region would be executed any more frequently).
> 
> The actual method I saw being compiled while holding the pending list lock was: java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference;
> 
> Other methods invoked from the locked region are:
> 
> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference;
> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;
> java/lang/Object.wait:()V
> 
> Of these java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; is also invoked outside of the locked region (it's actually at bci:0 - which is the target bci of the backward branches), and java/lang/Object.wait:()V is a native method.
> 
> 
> On 04/25/11 19:58, Tom Rodriguez wrote:
>> 
>> We could have a small side queue that we could enqueue these on and when a later safe request comes in we can request a non blocking compile of them.  It's kind of gross but it would work I think.  It could even just be a queue of length one instead of a full data structure.
>> 
>> tom
>> 
>>   
>> 
> I think having a special queue for these is a lot uglier than adapting the original fix (i.e. the one with the try_lock) to use ownership of the pending list lock rather than the thread id.
> 
> JohnC
> 


From tom.rodriguez at oracle.com  Tue Apr 26 11:54:02 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 26 Apr 2011 11:54:02 -0700
Subject: Request for reviews (XS): 7039586:
	test/java/util/Collections/Rotate.java failing with hs21-b09
In-Reply-To: <4DB70B6A.9080209@oracle.com>
References: <4DB70B6A.9080209@oracle.com>
Message-ID: <F354648B-3B57-448B-B788-D66B66425226@oracle.com>

Seems ok.

tom

On Apr 26, 2011, at 11:14 AM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/7039586/webrev
> 
> Fixed 7039586: test/java/util/Collections/Rotate.java failing with hs21-b09
> 
> A predicate should not be moved in partial peel optimization since it will invalidate jvm state of its uncommon trap.
> I looked on other places where a predicate is cloned and moved and they seems fine.


From vladimir.kozlov at oracle.com  Tue Apr 26 12:01:50 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 26 Apr 2011 12:01:50 -0700
Subject: Request for reviews (XS): 7039586:
	test/java/util/Collections/Rotate.java failing with hs21-b09
In-Reply-To: <F354648B-3B57-448B-B788-D66B66425226@oracle.com>
References: <4DB70B6A.9080209@oracle.com>
	<F354648B-3B57-448B-B788-D66B66425226@oracle.com>
Message-ID: <4DB7169E.3090906@oracle.com>

Thank you, Tom

Vladimir

Tom Rodriguez wrote:
> Seems ok.
> 
> tom
> 
> On Apr 26, 2011, at 11:14 AM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/7039586/webrev
>>
>> Fixed 7039586: test/java/util/Collections/Rotate.java failing with hs21-b09
>>
>> A predicate should not be moved in partial peel optimization since it will invalidate jvm state of its uncommon trap.
>> I looked on other places where a predicate is cloned and moved and they seems fine.
> 

From vladimir.kozlov at oracle.com  Tue Apr 26 22:41:48 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Wed, 27 Apr 2011 05:41:48 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7039586:
	test/java/util/Collections/Rotate.java failing with hs21-b09
Message-ID: <20110427054154.98EE44702F@hg.openjdk.java.net>

Changeset: 273b56978029
Author:    kvn
Date:      2011-04-26 12:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/273b56978029

7039586: test/java/util/Collections/Rotate.java failing with hs21-b09
Summary: A predicate should not be moved in partial peel optimization since it will invalidate jvm state of its uncommon trap.
Reviewed-by: never

! src/share/vm/opto/loopopts.cpp


From christian.thalinger at oracle.com  Wed Apr 27 00:28:50 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 27 Apr 2011 09:28:50 +0200
Subject: review (S) for 7030715: JSR 292 JRuby
	test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
In-Reply-To: <86E4AFC9-97FE-4BEB-B00A-1B8A65F8E508@oracle.com>
References: <86E4AFC9-97FE-4BEB-B00A-1B8A65F8E508@oracle.com>
Message-ID: <274F9EC8-7D3E-4760-976B-03FB78EE2F3D@oracle.com>

On Apr 21, 2011, at 10:47 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7030715
> 
> 7030715: JSR 292 JRuby test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
> Reviewed-by:
> 
> is_static shouldn't be called on unloaded ciMethods.  Instead of just
> adjusting the assert I decided to move the proper logic into ciMethod
> and modify the regular arg_size routine to complain if it's called on
> unloaded methods since it may return the wrong answer in that case.
> Tested with failing test and with CTW to ensure that the new assert
> doesn't trigger for other code.

For the record, I reviewed this one internally and it looks good.  -- Christian

From vladimir.kozlov at oracle.com  Wed Apr 27 16:17:23 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 27 Apr 2011 16:17:23 -0700
Subject: Request for reviews (XS): 7039652: Performance regression after
	7004547 changes
Message-ID: <4DB8A403.4090802@oracle.com>

http://cr.openjdk.java.net/~kvn/7039652/webrev

Fixed 7039652: Performance regression after 7004547 changes

In the test case initial stride is -8 so the loop is unrolled only once after 
7004547 changes moved next condition to the beginning of policy_unroll() method:

    // Check for stride being a small enough constant
    if (abs(cl->stride_con()) > (1<<3)) return false;

Before 7004547 changes that check was done at the end of policy_unroll() and the 
method returned 'true' if there were a lot 'xor' nodes in the loop regardless 
the stride check. As result the loop in the test case was unrolled twice.

The stride check serves additional purpose to limit unrolling to 16 (when 
initial stride is '1'). But as the test shows it may prevent legit unroll with 
bigger stride.

The fix is to use unrolled_count() to limit unrolling and use the stride check 
only for initial stride value. I don't understand why there is such limit on 
stride but it is for an other investigation (RFE).

I ran refworkload and don't see any affects from this fix.

From tom.rodriguez at oracle.com  Wed Apr 27 20:13:06 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Thu, 28 Apr 2011 03:13:06 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7029167: add support for conditional
	card marks
Message-ID: <20110428031313.A74204706F@hg.openjdk.java.net>

Changeset: 149bb459be66
Author:    never
Date:      2011-04-27 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/149bb459be66

7029167: add support for conditional card marks
Reviewed-by: iveresov, kvn

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/runtime/globals.hpp


From christian.thalinger at oracle.com  Thu Apr 28 06:38:04 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 28 Apr 2011 15:38:04 +0200
Subject: MaxRecursiveInlineLevel oddity
Message-ID: <78220B66-1108-4FB1-9292-84B45D459472@oracle.com>

While looking at JRuby performance and thus assembly code I noticed an oddity with recursive inlining:

$ java -XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintInlining -XX:MaxRecursiveInlineLevel=0 fib
VM option 'CICompilerCount=1'
VM option '+PrintCompilation'
VM option '+PrintInlining'
VM option 'MaxRecursiveInlineLevel=0'
    340    1             fib::fib (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
                            @ 16   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
    362    1 %           fib::main @ 2 (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep

It seems there is a "bug" in the logic in that it doesn't take the compiled method into account when counting the recursive inlining depth.  I expected when using MaxRecursiveInlineLevel=0 that there is no recursive inlining at all.

The simple example above shows that it might be possible that there are performance jumps between the various compiled methods as the recursive inlining depth changes.

I'd like to fix that (and I already have a fix that handles direct and indirect recursion) but the question is can we fix that given the possibility that it can change performance of applications?

-- Christian

From tom.rodriguez at oracle.com  Thu Apr 28 10:44:36 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 28 Apr 2011 10:44:36 -0700
Subject: MaxRecursiveInlineLevel oddity
In-Reply-To: <78220B66-1108-4FB1-9292-84B45D459472@oracle.com>
References: <78220B66-1108-4FB1-9292-84B45D459472@oracle.com>
Message-ID: <9F99DE78-AE0E-4012-98C9-5F33BBF0C033@oracle.com>

I believe there's actually a bug already filed about this.  It will certainly change the results of the inlining in rare cases but it seems reasonable to may it consistent.

tom

On Apr 28, 2011, at 6:38 AM, Christian Thalinger wrote:

> While looking at JRuby performance and thus assembly code I noticed an oddity with recursive inlining:
> 
> $ java -XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintInlining -XX:MaxRecursiveInlineLevel=0 fib
> VM option 'CICompilerCount=1'
> VM option '+PrintCompilation'
> VM option '+PrintInlining'
> VM option 'MaxRecursiveInlineLevel=0'
>    340    1             fib::fib (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                            @ 16   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>    362    1 %           fib::main @ 2 (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
> 
> It seems there is a "bug" in the logic in that it doesn't take the compiled method into account when counting the recursive inlining depth.  I expected when using MaxRecursiveInlineLevel=0 that there is no recursive inlining at all.
> 
> The simple example above shows that it might be possible that there are performance jumps between the various compiled methods as the recursive inlining depth changes.
> 
> I'd like to fix that (and I already have a fix that handles direct and indirect recursion) but the question is can we fix that given the possibility that it can change performance of applications?
> 
> -- Christian


From vladimir.kozlov at oracle.com  Thu Apr 28 10:56:34 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 28 Apr 2011 10:56:34 -0700
Subject: MaxRecursiveInlineLevel oddity
In-Reply-To: <9F99DE78-AE0E-4012-98C9-5F33BBF0C033@oracle.com>
References: <78220B66-1108-4FB1-9292-84B45D459472@oracle.com>
	<9F99DE78-AE0E-4012-98C9-5F33BBF0C033@oracle.com>
Message-ID: <4DB9AA52.9050708@oracle.com>

6552561: MaxRecursiveInlineLevel flag doesn't operate correctly

Tom Rodriguez wrote:
> I believe there's actually a bug already filed about this.  It will certainly change the results of the inlining in rare cases but it seems reasonable to may it consistent.
> 
> tom
> 
> On Apr 28, 2011, at 6:38 AM, Christian Thalinger wrote:
> 
>> While looking at JRuby performance and thus assembly code I noticed an oddity with recursive inlining:
>>
>> $ java -XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintInlining -XX:MaxRecursiveInlineLevel=0 fib
>> VM option 'CICompilerCount=1'
>> VM option '+PrintCompilation'
>> VM option '+PrintInlining'
>> VM option 'MaxRecursiveInlineLevel=0'
>>    340    1             fib::fib (21 bytes)
>>                            @ 10   fib::fib (21 bytes)   inline (hot)
>>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>>                            @ 16   fib::fib (21 bytes)   inline (hot)
>>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>>    362    1 %           fib::main @ 2 (21 bytes)
>>                            @ 10   fib::fib (21 bytes)   inline (hot)
>>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>>
>> It seems there is a "bug" in the logic in that it doesn't take the compiled method into account when counting the recursive inlining depth.  I expected when using MaxRecursiveInlineLevel=0 that there is no recursive inlining at all.
>>
>> The simple example above shows that it might be possible that there are performance jumps between the various compiled methods as the recursive inlining depth changes.
>>
>> I'd like to fix that (and I already have a fix that handles direct and indirect recursion) but the question is can we fix that given the possibility that it can change performance of applications?
>>
>> -- Christian
> 

From christian.thalinger at oracle.com  Thu Apr 28 11:01:17 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 28 Apr 2011 20:01:17 +0200
Subject: MaxRecursiveInlineLevel oddity
In-Reply-To: <4DB9AA52.9050708@oracle.com>
References: <78220B66-1108-4FB1-9292-84B45D459472@oracle.com>
	<9F99DE78-AE0E-4012-98C9-5F33BBF0C033@oracle.com>
	<4DB9AA52.9050708@oracle.com>
Message-ID: <A76B951F-736D-4E11-A9D2-4EA7538ED24F@oracle.com>

On Apr 28, 2011, at 7:56 PM, Vladimir Kozlov wrote:
> 6552561: MaxRecursiveInlineLevel flag doesn't operate correctly

Ohh, great.  I will send out a webrev.  -- Christian

> 
> Tom Rodriguez wrote:
>> I believe there's actually a bug already filed about this.  It will certainly change the results of the inlining in rare cases but it seems reasonable to may it consistent.
>> tom
>> On Apr 28, 2011, at 6:38 AM, Christian Thalinger wrote:
>>> While looking at JRuby performance and thus assembly code I noticed an oddity with recursive inlining:
>>> 
>>> $ java -XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintInlining -XX:MaxRecursiveInlineLevel=0 fib
>>> VM option 'CICompilerCount=1'
>>> VM option '+PrintCompilation'
>>> VM option '+PrintInlining'
>>> VM option 'MaxRecursiveInlineLevel=0'
>>>   340    1             fib::fib (21 bytes)
>>>                           @ 10   fib::fib (21 bytes)   inline (hot)
>>>                             @ 10   fib::fib (21 bytes)   recursively inlining too deep
>>>                             @ 16   fib::fib (21 bytes)   recursively inlining too deep
>>>                           @ 16   fib::fib (21 bytes)   inline (hot)
>>>                             @ 10   fib::fib (21 bytes)   recursively inlining too deep
>>>                             @ 16   fib::fib (21 bytes)   recursively inlining too deep
>>>   362    1 %           fib::main @ 2 (21 bytes)
>>>                           @ 10   fib::fib (21 bytes)   inline (hot)
>>>                             @ 10   fib::fib (21 bytes)   recursively inlining too deep
>>>                             @ 16   fib::fib (21 bytes)   recursively inlining too deep
>>> 
>>> It seems there is a "bug" in the logic in that it doesn't take the compiled method into account when counting the recursive inlining depth.  I expected when using MaxRecursiveInlineLevel=0 that there is no recursive inlining at all.
>>> 
>>> The simple example above shows that it might be possible that there are performance jumps between the various compiled methods as the recursive inlining depth changes.
>>> 
>>> I'd like to fix that (and I already have a fix that handles direct and indirect recursion) but the question is can we fix that given the possibility that it can change performance of applications?
>>> 
>>> -- Christian



From tom.rodriguez at oracle.com  Thu Apr 28 12:34:59 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 28 Apr 2011 12:34:59 -0700
Subject: Request for reviews (XS): 7039652: Performance regression after
	7004547 changes
In-Reply-To: <4DB8A403.4090802@oracle.com>
References: <4DB8A403.4090802@oracle.com>
Message-ID: <931BC8AF-F4D8-42F0-A501-8AA7C81BDB9C@oracle.com>

Seems ok.

tom

On Apr 27, 2011, at 4:17 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/7039652/webrev
> 
> Fixed 7039652: Performance regression after 7004547 changes
> 
> In the test case initial stride is -8 so the loop is unrolled only once after 7004547 changes moved next condition to the beginning of policy_unroll() method:
> 
>   // Check for stride being a small enough constant
>   if (abs(cl->stride_con()) > (1<<3)) return false;
> 
> Before 7004547 changes that check was done at the end of policy_unroll() and the method returned 'true' if there were a lot 'xor' nodes in the loop regardless the stride check. As result the loop in the test case was unrolled twice.
> 
> The stride check serves additional purpose to limit unrolling to 16 (when initial stride is '1'). But as the test shows it may prevent legit unroll with bigger stride.
> 
> The fix is to use unrolled_count() to limit unrolling and use the stride check only for initial stride value. I don't understand why there is such limit on stride but it is for an other investigation (RFE).
> 
> I ran refworkload and don't see any affects from this fix.


From tom.rodriguez at oracle.com  Thu Apr 28 13:55:42 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 28 Apr 2011 13:55:42 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
In-Reply-To: <D736CB6A-7DD6-45F4-9036-E40AB7C402B1@oracle.com>
References: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
	<4D9CD1CB.6060108@oracle.com>
	<CC3EAA09-A1B8-4CB7-B1D4-02379BFFD1C6@oracle.com>
	<4D9CD5FC.4090202@oracle.com>
	<D736CB6A-7DD6-45F4-9036-E40AB7C402B1@oracle.com>
Message-ID: <6EA2A4E9-0471-4A2A-92FD-8B822DE2AC50@oracle.com>

The push for this failed just before my vacation and I didn't have time to investigate then.  It turns out that the klass() call needs to guard against the null object so it now looks like this:

diff -r 149bb459be66 src/share/vm/ci/ciObject.cpp                                                                                            
--- a/src/share/vm/ci/ciObject.cpp                                                                                                          
+++ b/src/share/vm/ci/ciObject.cpp                                                                                                          
@@ -194,6 +194,16 @@
 // ciObject::should_be_constant()                                                                                                          
 bool ciObject::should_be_constant() {                                                                                                      
   if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                          
+  if (!JavaObjectsInPerm && !is_null_object()) {                                                                                            
+    // We want Strings and Classes to be embeddable by default since                                                                        
+    // they used to be in the perm world.  Not all Strings used to be                                                                      
+    // embeddable but there's no easy way to distinguish the interned                                                                      
+    // from the regulars ones so just treat them all that way.                                                                              
+    ciEnv* env = CURRENT_ENV;                                                                                                              
+    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                  
+      return true;                                                                                                                          
+    }                                                                                                                                      
+  }                                                                                                                                        
   return handle() == NULL || !is_scavengable();                                                                                            
 }

tom

On Apr 6, 2011, at 3:52 PM, Tom Rodriguez wrote:

> Thanks!
> 
> tom
> 
> On Apr 6, 2011, at 2:07 PM, Vladimir Kozlov wrote:
> 
>> This looks better.
>> 
>> Thanks,
>> Vladimir
>> 
>> Tom Rodriguez wrote:
>>> On Apr 6, 2011, at 1:49 PM, Vladimir Kozlov wrote:
>>>> You replaced 'require_constant' with 'true' to the call make_from_constant() so I was wondering if it may change behavior. Specifically it may produce NULL now
>>>> if oop_constant->can_be_constant() is 'false':
>>>> 
>>>>    if (require_constant) {
>>>>      if (!o->can_be_constant())  return NULL;
>>> In the !JavaObjectInPerm world Strings should always return true for can_be_constant.  Actually I think it would be better to fix it by changing ciObject::should_be_constant instead of just patching that use. I also included Classes in the test for consistency with the old behaviour.  So I've removed the changes in parse3.cpp and done this instead.
>>> diff -r 8e77e1f26188 src/share/vm/ci/ciObject.cpp                                                                                                     --- a/src/share/vm/ci/ciObject.cpp                                                                                                                   +++ b/src/share/vm/ci/ciObject.cpp                                                                                                                   @@ -194,6 +194,16 @@ bool ciObject::can_be_constant() {
>>> // ciObject::should_be_constant()                                                                                                                    bool ciObject::should_be_constant() {                                                                                                                  if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                                   +  if (!JavaObjectsInPerm) {                                                                                                                         +    // We want Strings and Classes to be embeddable by default since                                                                                 +    // they used to be in the perm world.  Not all Strings used to be                                                                               +    // embeddable but there's no easy way to distinguish the interned                                                                               +    // from the regulars ones so just treat them all that way.                                                                                       +    ciEnv* env = CURRENT_ENV;                                                                                                                       +    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                           +      return true;                                                                                                                                   +    }                                                                                                                                               +  }                                                                                                                                                    return handle() == NULL || !is_scavengable();                                                                                                      }
>>> tom
>>>> Vladimir
>>>> 
>>>> Tom Rodriguez wrote:
>>>>> http://cr.openjdk.java.net/~never/7032162
>>>>> 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
>>>>> Reviewed-by:
>>>>> This appears to be an existing problem with OptimizeStringConcat where
>>>>> missing control can allow some loads to be split up to where their
>>>>> base is NULL which causes addresses that can't be analyzed.  The fix
>>>>> is to use the appropriate control.  If it's truly unneeded it will be
>>>>> optimized away.  The bug was exposed by the String not in perm changes
>>>>> because we were no longer treating some constant strings as embeddable
>>>>> constants.  This is fixed by handling them specially in push_constant.
>>>>> Tested with failing test from report and full CTW with string opts.
> 


From vladimir.kozlov at oracle.com  Thu Apr 28 14:32:40 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 28 Apr 2011 14:32:40 -0700
Subject: Request for reviews (XS): 7039652: Performance regression after
	7004547 changes
In-Reply-To: <931BC8AF-F4D8-42F0-A501-8AA7C81BDB9C@oracle.com>
References: <4DB8A403.4090802@oracle.com>
	<931BC8AF-F4D8-42F0-A501-8AA7C81BDB9C@oracle.com>
Message-ID: <4DB9DCF8.5000704@oracle.com>

Thank you, Tom

Vladimir

Tom Rodriguez wrote:
> Seems ok.
> 
> tom
> 
> On Apr 27, 2011, at 4:17 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/7039652/webrev
>>
>> Fixed 7039652: Performance regression after 7004547 changes
>>
>> In the test case initial stride is -8 so the loop is unrolled only once after 7004547 changes moved next condition to the beginning of policy_unroll() method:
>>
>>   // Check for stride being a small enough constant
>>   if (abs(cl->stride_con()) > (1<<3)) return false;
>>
>> Before 7004547 changes that check was done at the end of policy_unroll() and the method returned 'true' if there were a lot 'xor' nodes in the loop regardless the stride check. As result the loop in the test case was unrolled twice.
>>
>> The stride check serves additional purpose to limit unrolling to 16 (when initial stride is '1'). But as the test shows it may prevent legit unroll with bigger stride.
>>
>> The fix is to use unrolled_count() to limit unrolling and use the stride check only for initial stride value. I don't understand why there is such limit on stride but it is for an other investigation (RFE).
>>
>> I ran refworkload and don't see any affects from this fix.
> 

From vladimir.kozlov at oracle.com  Thu Apr 28 14:37:37 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 28 Apr 2011 14:37:37 -0700
Subject: review (S) for 7032162: assert(flat != TypePtr::BOTTOM) failed:
	cannot alias-analyze an untyped ptr
In-Reply-To: <6EA2A4E9-0471-4A2A-92FD-8B822DE2AC50@oracle.com>
References: <2CB28301-5C75-40B2-851D-6808CB0200B9@oracle.com>
	<4D9CD1CB.6060108@oracle.com>
	<CC3EAA09-A1B8-4CB7-B1D4-02379BFFD1C6@oracle.com>
	<4D9CD5FC.4090202@oracle.com>
	<D736CB6A-7DD6-45F4-9036-E40AB7C402B1@oracle.com>
	<6EA2A4E9-0471-4A2A-92FD-8B822DE2AC50@oracle.com>
Message-ID: <4DB9DE21.7030609@oracle.com>

Good.

Vladimir

Tom Rodriguez wrote:
> The push for this failed just before my vacation and I didn't have time to investigate then.  It turns out that the klass() call needs to guard against the null object so it now looks like this:
> 
> diff -r 149bb459be66 src/share/vm/ci/ciObject.cpp                                                                                            
> --- a/src/share/vm/ci/ciObject.cpp                                                                                                          
> +++ b/src/share/vm/ci/ciObject.cpp                                                                                                          
> @@ -194,6 +194,16 @@
>  // ciObject::should_be_constant()                                                                                                          
>  bool ciObject::should_be_constant() {                                                                                                      
>    if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                          
> +  if (!JavaObjectsInPerm && !is_null_object()) {                                                                                            
> +    // We want Strings and Classes to be embeddable by default since                                                                        
> +    // they used to be in the perm world.  Not all Strings used to be                                                                      
> +    // embeddable but there's no easy way to distinguish the interned                                                                      
> +    // from the regulars ones so just treat them all that way.                                                                              
> +    ciEnv* env = CURRENT_ENV;                                                                                                              
> +    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                  
> +      return true;                                                                                                                          
> +    }                                                                                                                                      
> +  }                                                                                                                                        
>    return handle() == NULL || !is_scavengable();                                                                                            
>  }
> 
> tom
> 
> On Apr 6, 2011, at 3:52 PM, Tom Rodriguez wrote:
> 
>> Thanks!
>>
>> tom
>>
>> On Apr 6, 2011, at 2:07 PM, Vladimir Kozlov wrote:
>>
>>> This looks better.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> On Apr 6, 2011, at 1:49 PM, Vladimir Kozlov wrote:
>>>>> You replaced 'require_constant' with 'true' to the call make_from_constant() so I was wondering if it may change behavior. Specifically it may produce NULL now
>>>>> if oop_constant->can_be_constant() is 'false':
>>>>>
>>>>>    if (require_constant) {
>>>>>      if (!o->can_be_constant())  return NULL;
>>>> In the !JavaObjectInPerm world Strings should always return true for can_be_constant.  Actually I think it would be better to fix it by changing ciObject::should_be_constant instead of just patching that use. I also included Classes in the test for consistency with the old behaviour.  So I've removed the changes in parse3.cpp and done this instead.
>>>> diff -r 8e77e1f26188 src/share/vm/ci/ciObject.cpp                                                                                                     --- a/src/share/vm/ci/ciObject.cpp                                                                                                                   +++ b/src/share/vm/ci/ciObject.cpp                                                                                                                   @@ -194,6 +194,16 @@ bool ciObject::can_be_constant() {
>>>> // ciObject::should_be_constant()                                                                                                                    bool ciObject::should_be_constant() {                                                                                                                  if (ScavengeRootsInCode >= 2)  return true;  // force everybody to be a constant                                                                   +  if (!JavaObjectsInPerm) {                                                                                                                         +    // We want Strings and Classes to be embeddable by default since                                                                                 +    // they used to be in the perm world.  Not all Strings used to be                                                                               +    // embeddable but there's no easy way to distinguish the interned                    
                                                           +    // from the regulars ones so just treat them all that way.                                                                                       +    ciEnv* env = CURRENT_ENV;                                                                                                                       +    if (klass() == env->String_klass() || klass() == env->Class_klass()) {                                                                           +      return true;                                                                                                                                   +    }                                                                                                                                               +  }                                                                                                                                                    return handle() == NULL || !is_
scavengable();                                                                                                      }
>>>> tom
>>>>> Vladimir
>>>>>
>>>>> Tom Rodriguez wrote:
>>>>>> http://cr.openjdk.java.net/~never/7032162
>>>>>> 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
>>>>>> Reviewed-by:
>>>>>> This appears to be an existing problem with OptimizeStringConcat where
>>>>>> missing control can allow some loads to be split up to where their
>>>>>> base is NULL which causes addresses that can't be analyzed.  The fix
>>>>>> is to use the appropriate control.  If it's truly unneeded it will be
>>>>>> optimized away.  The bug was exposed by the String not in perm changes
>>>>>> because we were no longer treating some constant strings as embeddable
>>>>>> constants.  This is fixed by handling them specially in push_constant.
>>>>>> Tested with failing test from report and full CTW with string opts.
> 

From vladimir.kozlov at oracle.com  Thu Apr 28 16:04:42 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 28 Apr 2011 16:04:42 -0700
Subject: Request for reviews (XXL): 5091921: Sign flip issues in loop optimizer
Message-ID: <4DB9F28A.8020105@oracle.com>

http://cr.openjdk.java.net/~kvn/5091921/webrev

Fixed 5091921: Sign flip issues in loop optimizer

Loop optimizer in Server VM does not take into account integer overflow when it 
generates code for loop limits calculation during counted loop construction, 
unrolling and range check elimination. As result generated code will behave 
incorrectly when an integer overflow happens.

1. Added limit check for Counted loops which, if failed, causes recompilation of 
the method without counted loop. It based on loop predication code we have 
already but we don't need to copy it after corresponding counted loop is created 
(this is why a new flag is passed to loop predicate copy methods).

if (limit>= max_int-stride)
   uncommon_trap
counted_loop init, limit, stride

2. Long arithmetic is used to calculate exact limit only when it is needed: 
empty loop elimination and predicated range check elimination. New ideal macro 
node LoopLimitNode is used but corresponding mach node is created only for 
32-bit x86 to get better assembler code. Sparc and x64 have long registers so 
generated assembler is good enough without specialized mach node. Also delay 
LoopLimitNode transformation until all loop optimizations are done (by marking 
LoopLimitNode as macro node).

3. New limit after unroll calculated as:

   new_limit = limit-stride
   new_limit = (limit < new_limit) ? MININT : new_limit;

instead of current expression:

   new_limit = init + (((limit-init)/stride)&(-2))*stride

Added other checks to avoid limit value overflow during unroll. Also fully 
unroll loops with up to 3 trip count.

4. Added underflow check for normal compares in loops which are optimized out 
using range check elimination code (I also refactored the code):

  MIN_INT <= scale*I+offset < limit

----------------------------------------------
These changes are put under flags to debug associated problems. I also allowed 
to print inlining decisions in product VM since PrintInlining is diagnostic flag 
now. New regression tests are added based on associated bug reports.

These changes cause performance regression in benchmarks. Some of regression 
cases can't not be avoided but some we will address in a future.

And finally I want to thank java VM team from HP who provided nice test cases 
and even suggested fix. I used their idea for unroll limit fix.

From tom.rodriguez at oracle.com  Thu Apr 28 16:51:45 2011
From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com)
Date: Thu, 28 Apr 2011 23:51:45 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7032162: assert(flat !=
	TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
Message-ID: <20110428235147.8BCA5470C6@hg.openjdk.java.net>

Changeset: 01fd6090fdd8
Author:    never
Date:      2011-04-28 14:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/01fd6090fdd8

7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
Reviewed-by: kvn

! src/share/vm/ci/ciObject.cpp
! src/share/vm/opto/stringopts.cpp


From vladimir.kozlov at oracle.com  Thu Apr 28 21:44:38 2011
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 29 Apr 2011 04:44:38 +0000
Subject: hg: jdk7/hotspot-comp/hotspot: 7039652: Performance regression after
	7004547 changes
Message-ID: <20110429044442.5A3A4470D3@hg.openjdk.java.net>

Changeset: ae93231c7a1f
Author:    kvn
Date:      2011-04-28 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ae93231c7a1f

7039652: Performance regression after 7004547 changes
Summary: Use unrolled_count() to limit unrolling and use the stride check only for initial stride value.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp


From christian.thalinger at oracle.com  Fri Apr 29 04:03:03 2011
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 29 Apr 2011 13:03:03 +0200
Subject: Request for reviews (XS): 6552561: MaxRecursiveInlineLevel flag
	doesn't operate correctly
Message-ID: <04CB0C21-36F0-411A-AAB6-89C49A9A1D39@oracle.com>

http://cr.openjdk.java.net/~twisti/6552561/

6552561: MaxRecursiveInlineLevel flag doesn't operate correctly
Reviewed-by:

The current logic around MaxRecursiveInlineLevel does not calculate
the inline depth correctly in some situations resulting in different
recursive inlining depending on the compiled method.

The fix is to use the logic we already use for recursive method handle
targets.  This also handles indirect recursion correctly.

src/share/vm/opto/bytecodeInfo.cpp

---

Some before-after examples:

1. Direct recursive inlining...

...with -XX:MaxRecursiveInlineLevel=1:

Before:

    282    1             fib::fib (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
                            @ 16   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
    301    1 %           fib::main @ 2 (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep

Results in different recursive inlining in the two compiles (2 vs. 1).

After:

    673    1             fib::fib (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
                            @ 16   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
    702    1 %           fib::main @ 2 (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   inline (hot)
                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
                                @ 16   fib::fib (21 bytes)   recursively inlining too deep

...with -XX:MaxRecursiveInlineLevel=0:

Before:

    396    1             fib::fib (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
                            @ 16   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
    414    1 %           fib::main @ 2 (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep

Results in different recursive inlining in the two compiles (1 vs. 0).

After:

    602    1             fib::fib (21 bytes)
                            @ 10   fib::fib (21 bytes)   recursively inlining too deep
                            @ 16   fib::fib (21 bytes)   recursively inlining too deep
    633    1 %           fib::main @ 2 (21 bytes)
                            @ 10   fib::fib (21 bytes)   inline (hot)
                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
                              @ 16   fib::fib (21 bytes)   recursively inlining too deep

2. Indirect recursive inlining...

...with -XX:MaxRecursiveInlineLevel=1:

Before:

    292    1 %           indirect::main @ 2 (21 bytes)
                            @ 10   indirect::foo (14 bytes)   inline (hot)
                              @ 10   indirect::bar (14 bytes)   inline (hot)
                                @ 10   indirect::foo (14 bytes)   inline (hot)
                                    @ 10   indirect::foo (14 bytes)   inline (hot)
                                      @ 10   indirect::bar (14 bytes)   inline (hot)
                                        @ 10   indirect::foo (14 bytes)   inline (hot)
                                          @ 10   indirect::bar (14 bytes)   inline (hot)
                                            @ 10   indirect::foo (14 bytes)   inline (hot)
                                              @ 10   indirect::bar (14 bytes)   inline (hot)
                                                @ 10   indirect::foo (14 bytes)   inlining too deep

Indirect recursive inlining not handled at all, the logic inlines until MaxInlineLevel is hit (which is 9 by default).

After:

    624    1 %           indirect::main @ 2 (21 bytes)
                            @ 10   indirect::foo (14 bytes)   inline (hot)
                              @ 10   indirect::bar (14 bytes)   inline (hot)
                                @ 10   indirect::foo (14 bytes)   inline (hot)
                                  @ 10   indirect::bar (14 bytes)   inline (hot)
                                    @ 10   indirect::foo (14 bytes)   recursively inlining too deep

Every recursive call is inlined once.

...with -XX:MaxRecursiveInlineLevel=0:

After:

    602    1             indirect::foo (14 bytes)
                            @ 10   indirect::bar (14 bytes)   inline (hot)
                              @ 10   indirect::foo (14 bytes)   recursively inlining too deep
    621    2             indirect::bar (14 bytes)
                            @ 10   indirect::foo (14 bytes)   inline (hot)
                              @ 10   indirect::bar (14 bytes)   recursively inlining too deep
    623    1 %           indirect::main @ 2 (21 bytes)
                            @ 10   indirect::foo (14 bytes)   inline (hot)
                              @ 10   indirect::bar (14 bytes)   inline (hot)
                                @ 10   indirect::foo (14 bytes)   recursively inlining too deep

No recursive inlining.

From Dmitry.Samersoff at oracle.com  Fri Apr 29 03:19:19 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 29 Apr 2011 14:19:19 +0400
Subject: Request for reviews (XXL): 5091921: Sign flip issues in loop
	optimizer
In-Reply-To: <4DB9F28A.8020105@oracle.com>
References: <4DB9F28A.8020105@oracle.com>
Message-ID: <4DBA90A7.2070600@oracle.com>

Vladimir,

Thank you in advance for fixing it!

-Dmitry


On 2011-04-29 03:04, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/5091921/webrev
>
> Fixed 5091921: Sign flip issues in loop optimizer
>
> Loop optimizer in Server VM does not take into account integer overflow
> when it generates code for loop limits calculation during counted loop
> construction, unrolling and range check elimination. As result generated
> code will behave incorrectly when an integer overflow happens.
>
> 1. Added limit check for Counted loops which, if failed, causes
> recompilation of the method without counted loop. It based on loop
> predication code we have already but we don't need to copy it after
> corresponding counted loop is created (this is why a new flag is passed
> to loop predicate copy methods).
>
> if (limit>= max_int-stride)
> uncommon_trap
> counted_loop init, limit, stride
>
> 2. Long arithmetic is used to calculate exact limit only when it is
> needed: empty loop elimination and predicated range check elimination.
> New ideal macro node LoopLimitNode is used but corresponding mach node
> is created only for 32-bit x86 to get better assembler code. Sparc and
> x64 have long registers so generated assembler is good enough without
> specialized mach node. Also delay LoopLimitNode transformation until all
> loop optimizations are done (by marking LoopLimitNode as macro node).
>
> 3. New limit after unroll calculated as:
>
> new_limit = limit-stride
> new_limit = (limit < new_limit) ? MININT : new_limit;
>
> instead of current expression:
>
> new_limit = init + (((limit-init)/stride)&(-2))*stride
>
> Added other checks to avoid limit value overflow during unroll. Also
> fully unroll loops with up to 3 trip count.
>
> 4. Added underflow check for normal compares in loops which are
> optimized out using range check elimination code (I also refactored the
> code):
>
> MIN_INT <= scale*I+offset < limit
>
> ----------------------------------------------
> These changes are put under flags to debug associated problems. I also
> allowed to print inlining decisions in product VM since PrintInlining is
> diagnostic flag now. New regression tests are added based on associated
> bug reports.
>
> These changes cause performance regression in benchmarks. Some of
> regression cases can't not be avoided but some we will address in a future.
>
> And finally I want to thank java VM team from HP who provided nice test
> cases and even suggested fix. I used their idea for unroll limit fix.


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

From vladimir.kozlov at oracle.com  Fri Apr 29 10:09:10 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 29 Apr 2011 10:09:10 -0700
Subject: Request for reviews (XS): 6552561: MaxRecursiveInlineLevel flag
	doesn't operate correctly
In-Reply-To: <04CB0C21-36F0-411A-AAB6-89C49A9A1D39@oracle.com>
References: <04CB0C21-36F0-411A-AAB6-89C49A9A1D39@oracle.com>
Message-ID: <4DBAF0B6.1060203@oracle.com>

Looks good. Thank you for fixing this.

Vladimir

On 4/29/11 4:03 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/6552561/
>
> 6552561: MaxRecursiveInlineLevel flag doesn't operate correctly
> Reviewed-by:
>
> The current logic around MaxRecursiveInlineLevel does not calculate
> the inline depth correctly in some situations resulting in different
> recursive inlining depending on the compiled method.
>
> The fix is to use the logic we already use for recursive method handle
> targets.  This also handles indirect recursion correctly.
>
> src/share/vm/opto/bytecodeInfo.cpp
>
> ---
>
> Some before-after examples:
>
> 1. Direct recursive inlining...
>
> ...with -XX:MaxRecursiveInlineLevel=1:
>
> Before:
>
>      282    1             fib::fib (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>      301    1 %           fib::main @ 2 (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>
> Results in different recursive inlining in the two compiles (2 vs. 1).
>
> After:
>
>      673    1             fib::fib (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>      702    1 %           fib::main @ 2 (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   inline (hot)
>                                  @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                  @ 16   fib::fib (21 bytes)   recursively inlining too deep
>
> ...with -XX:MaxRecursiveInlineLevel=0:
>
> Before:
>
>      396    1             fib::fib (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>      414    1 %           fib::main @ 2 (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>
> Results in different recursive inlining in the two compiles (1 vs. 0).
>
> After:
>
>      602    1             fib::fib (21 bytes)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>      633    1 %           fib::main @ 2 (21 bytes)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>
> 2. Indirect recursive inlining...
>
> ...with -XX:MaxRecursiveInlineLevel=1:
>
> Before:
>
>      292    1 %           indirect::main @ 2 (21 bytes)
>                              @ 10   indirect::foo (14 bytes)   inline (hot)
>                                @ 10   indirect::bar (14 bytes)   inline (hot)
>                                  @ 10   indirect::foo (14 bytes)   inline (hot)
>                                      @ 10   indirect::foo (14 bytes)   inline (hot)
>                                        @ 10   indirect::bar (14 bytes)   inline (hot)
>                                          @ 10   indirect::foo (14 bytes)   inline (hot)
>                                            @ 10   indirect::bar (14 bytes)   inline (hot)
>                                              @ 10   indirect::foo (14 bytes)   inline (hot)
>                                                @ 10   indirect::bar (14 bytes)   inline (hot)
>                                                  @ 10   indirect::foo (14 bytes)   inlining too deep
>
> Indirect recursive inlining not handled at all, the logic inlines until MaxInlineLevel is hit (which is 9 by default).
>
> After:
>
>      624    1 %           indirect::main @ 2 (21 bytes)
>                              @ 10   indirect::foo (14 bytes)   inline (hot)
>                                @ 10   indirect::bar (14 bytes)   inline (hot)
>                                  @ 10   indirect::foo (14 bytes)   inline (hot)
>                                    @ 10   indirect::bar (14 bytes)   inline (hot)
>                                      @ 10   indirect::foo (14 bytes)   recursively inlining too deep
>
> Every recursive call is inlined once.
>
> ...with -XX:MaxRecursiveInlineLevel=0:
>
> After:
>
>      602    1             indirect::foo (14 bytes)
>                              @ 10   indirect::bar (14 bytes)   inline (hot)
>                                @ 10   indirect::foo (14 bytes)   recursively inlining too deep
>      621    2             indirect::bar (14 bytes)
>                              @ 10   indirect::foo (14 bytes)   inline (hot)
>                                @ 10   indirect::bar (14 bytes)   recursively inlining too deep
>      623    1 %           indirect::main @ 2 (21 bytes)
>                              @ 10   indirect::foo (14 bytes)   inline (hot)
>                                @ 10   indirect::bar (14 bytes)   inline (hot)
>                                  @ 10   indirect::foo (14 bytes)   recursively inlining too deep
>
> No recursive inlining.

From tom.rodriguez at oracle.com  Fri Apr 29 10:37:11 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 29 Apr 2011 10:37:11 -0700
Subject: Request for reviews (XS): 6552561: MaxRecursiveInlineLevel flag
	doesn't operate correctly
In-Reply-To: <04CB0C21-36F0-411A-AAB6-89C49A9A1D39@oracle.com>
References: <04CB0C21-36F0-411A-AAB6-89C49A9A1D39@oracle.com>
Message-ID: <28BE1828-30CD-423F-AF7E-4468A5203E26@oracle.com>

Looks good.

tom

On Apr 29, 2011, at 4:03 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/6552561/
> 
> 6552561: MaxRecursiveInlineLevel flag doesn't operate correctly
> Reviewed-by:
> 
> The current logic around MaxRecursiveInlineLevel does not calculate
> the inline depth correctly in some situations resulting in different
> recursive inlining depending on the compiled method.
> 
> The fix is to use the logic we already use for recursive method handle
> targets.  This also handles indirect recursion correctly.
> 
> src/share/vm/opto/bytecodeInfo.cpp
> 
> ---
> 
> Some before-after examples:
> 
> 1. Direct recursive inlining...
> 
> ...with -XX:MaxRecursiveInlineLevel=1:
> 
> Before:
> 
>    282    1             fib::fib (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                            @ 16   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>    301    1 %           fib::main @ 2 (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
> 
> Results in different recursive inlining in the two compiles (2 vs. 1).
> 
> After:
> 
>    673    1             fib::fib (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                            @ 16   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>    702    1 %           fib::main @ 2 (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   inline (hot)
>                                @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                                @ 16   fib::fib (21 bytes)   recursively inlining too deep
> 
> ...with -XX:MaxRecursiveInlineLevel=0:
> 
> Before:
> 
>    396    1             fib::fib (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>                            @ 16   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
>    414    1 %           fib::main @ 2 (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
> 
> Results in different recursive inlining in the two compiles (1 vs. 0).
> 
> After:
> 
>    602    1             fib::fib (21 bytes)
>                            @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                            @ 16   fib::fib (21 bytes)   recursively inlining too deep
>    633    1 %           fib::main @ 2 (21 bytes)
>                            @ 10   fib::fib (21 bytes)   inline (hot)
>                              @ 10   fib::fib (21 bytes)   recursively inlining too deep
>                              @ 16   fib::fib (21 bytes)   recursively inlining too deep
> 
> 2. Indirect recursive inlining...
> 
> ...with -XX:MaxRecursiveInlineLevel=1:
> 
> Before:
> 
>    292    1 %           indirect::main @ 2 (21 bytes)
>                            @ 10   indirect::foo (14 bytes)   inline (hot)
>                              @ 10   indirect::bar (14 bytes)   inline (hot)
>                                @ 10   indirect::foo (14 bytes)   inline (hot)
>                                    @ 10   indirect::foo (14 bytes)   inline (hot)
>                                      @ 10   indirect::bar (14 bytes)   inline (hot)
>                                        @ 10   indirect::foo (14 bytes)   inline (hot)
>                                          @ 10   indirect::bar (14 bytes)   inline (hot)
>                                            @ 10   indirect::foo (14 bytes)   inline (hot)
>                                              @ 10   indirect::bar (14 bytes)   inline (hot)
>                                                @ 10   indirect::foo (14 bytes)   inlining too deep
> 
> Indirect recursive inlining not handled at all, the logic inlines until MaxInlineLevel is hit (which is 9 by default).
> 
> After:
> 
>    624    1 %           indirect::main @ 2 (21 bytes)
>                            @ 10   indirect::foo (14 bytes)   inline (hot)
>                              @ 10   indirect::bar (14 bytes)   inline (hot)
>                                @ 10   indirect::foo (14 bytes)   inline (hot)
>                                  @ 10   indirect::bar (14 bytes)   inline (hot)
>                                    @ 10   indirect::foo (14 bytes)   recursively inlining too deep
> 
> Every recursive call is inlined once.
> 
> ...with -XX:MaxRecursiveInlineLevel=0:
> 
> After:
> 
>    602    1             indirect::foo (14 bytes)
>                            @ 10   indirect::bar (14 bytes)   inline (hot)
>                              @ 10   indirect::foo (14 bytes)   recursively inlining too deep
>    621    2             indirect::bar (14 bytes)
>                            @ 10   indirect::foo (14 bytes)   inline (hot)
>                              @ 10   indirect::bar (14 bytes)   recursively inlining too deep
>    623    1 %           indirect::main @ 2 (21 bytes)
>                            @ 10   indirect::foo (14 bytes)   inline (hot)
>                              @ 10   indirect::bar (14 bytes)   inline (hot)
>                                @ 10   indirect::foo (14 bytes)   recursively inlining too deep
> 
> No recursive inlining.


From tom.rodriguez at oracle.com  Fri Apr 29 15:29:52 2011
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 29 Apr 2011 15:29:52 -0700
Subject: review for 7009361: JSR 292 Invalid value on stack on solaris-sparc
	with -Xcomp
Message-ID: <BA01E9F7-660E-487B-AAD6-6FDB47BB9D4A@oracle.com>

http://cr.openjdk.java.net/~never/7009361

7009361: JSR 292 Invalid value on stack on solaris-sparc with -Xcomp
Reviewed-by:

In the invokedynamic world the signature of the method at an invoke
bytecode might note be the same as the signature of the callee you
finally end up in.  This all works correctly during normal execution
but it can break the logic that deopt uses to layout the frames.  In
particular on sparc we attempt to place the locals in the same
location that the interpreter execution would have produced by using
the callers expression stack address and callee->size_of_parameters()
to figure out where the top of the live stack is.  If the size of the
parameters at the original call site is less than the size of the
parameters of the actual callee then the locals will end up top of the
callers live expression stack.  The x86 version of this code places
the locals at the bottom of the frame which keeps this from happening
and I've modified sparc to do the same.  There's no reason they need
to be in the same location.

The other potential problem is that deopt also has logic that makes
sure the existing caller is enlarged enough to account for the
difference between the callee parameters and the callee locals.  In
the current world we don't really need to enlarge this space because
the method handle machinery also operates like the interpreter so it
extends the caller frame when injecting extra arguments, thus making
sure there's really enough space when we deopt.  Since it doesn't have
to work this way I decided to fix this logic to grab the caller notion
of the number of arguments and correct the last frame adjust using
this value.

Additionally the TraceMethodHandles logic was very broken in x86 so I
fixed it.  It was mainly broken because some of the
trace_method_handle calls are generated using an
InterpreterMacroAssembler which has extra asserts in call_VM_leaf_base
that don't really apply for the method handle adapters.  There were
also problems with the number of arguments being passed in 64 bit.  I
ended up moving super_call_VM_leaf up into MacroAssembler since
there's no way to figure out that you are using an
InterpreterMacroAssembler versus a MacroAssembler.

To debug this I added a new printing function,
JavaThread::print_frame_layout, that prints an annotated view of the
stack memory similar to what the SA's memory viewer does.  It also
includes some logic to check that the space owned by a frame isn't
claimed by another frame.  That actually detects the original bug
immediately.  It's not as full featured as it might be but it reports
everything you need to know about interpreter frames.

I also made a small change in loopPredicate because the ttyLocker was
producing spurious output in the log all the time.

Tested with original failing test from test and DeoptimizeALot testing
on sparc.


From vladimir.kozlov at oracle.com  Fri Apr 29 23:05:05 2011
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 29 Apr 2011 23:05:05 -0700
Subject: review for 7009361: JSR 292 Invalid value on stack on
	solaris-sparc with -Xcomp
In-Reply-To: <BA01E9F7-660E-487B-AAD6-6FDB47BB9D4A@oracle.com>
References: <BA01E9F7-660E-487B-AAD6-6FDB47BB9D4A@oracle.com>
Message-ID: <4DBBA691.5090904@oracle.com>

Looks fine as far as I understand it and thank you for fixing loop predicates output.
One thing which was not clear is registers usage in 32-bit code in trace_method_handle() in methodHandles_x86.cpp. Yes, 
from caller of trace_method_handle() you can find it out but in trace_method_handle() it looks like mess.

Vladimir

On 4/29/11 3:29 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/7009361
>
> 7009361: JSR 292 Invalid value on stack on solaris-sparc with -Xcomp
> Reviewed-by:
>
> In the invokedynamic world the signature of the method at an invoke
> bytecode might note be the same as the signature of the callee you
> finally end up in.  This all works correctly during normal execution
> but it can break the logic that deopt uses to layout the frames.  In
> particular on sparc we attempt to place the locals in the same
> location that the interpreter execution would have produced by using
> the callers expression stack address and callee->size_of_parameters()
> to figure out where the top of the live stack is.  If the size of the
> parameters at the original call site is less than the size of the
> parameters of the actual callee then the locals will end up top of the
> callers live expression stack.  The x86 version of this code places
> the locals at the bottom of the frame which keeps this from happening
> and I've modified sparc to do the same.  There's no reason they need
> to be in the same location.
>
> The other potential problem is that deopt also has logic that makes
> sure the existing caller is enlarged enough to account for the
> difference between the callee parameters and the callee locals.  In
> the current world we don't really need to enlarge this space because
> the method handle machinery also operates like the interpreter so it
> extends the caller frame when injecting extra arguments, thus making
> sure there's really enough space when we deopt.  Since it doesn't have
> to work this way I decided to fix this logic to grab the caller notion
> of the number of arguments and correct the last frame adjust using
> this value.
>
> Additionally the TraceMethodHandles logic was very broken in x86 so I
> fixed it.  It was mainly broken because some of the
> trace_method_handle calls are generated using an
> InterpreterMacroAssembler which has extra asserts in call_VM_leaf_base
> that don't really apply for the method handle adapters.  There were
> also problems with the number of arguments being passed in 64 bit.  I
> ended up moving super_call_VM_leaf up into MacroAssembler since
> there's no way to figure out that you are using an
> InterpreterMacroAssembler versus a MacroAssembler.
>
> To debug this I added a new printing function,
> JavaThread::print_frame_layout, that prints an annotated view of the
> stack memory similar to what the SA's memory viewer does.  It also
> includes some logic to check that the space owned by a frame isn't
> claimed by another frame.  That actually detects the original bug
> immediately.  It's not as full featured as it might be but it reports
> everything you need to know about interpreter frames.
>
> I also made a small change in loopPredicate because the ttyLocker was
> producing spurious output in the log all the time.
>
> Tested with original failing test from test and DeoptimizeALot testing
> on sparc.
>