RFR 8155047: [JVMCI] findLeafConcreteSubtype should handle arrays of leaf concrete subtype

[Christian Thalinger]

> On May 12, 2016, at 6:29 AM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
> So can I considered this reviewed?

Sorry, yes.

> 
> tom
> 
>> On Apr 28, 2016, at 4:55 PM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>> 
>> 
>>> On Apr 28, 2016, at 12:23 PM, Christian Thalinger <christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>> wrote:
>>> 
>>> 
>>>> On Apr 28, 2016, at 6:13 AM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>>>> 
>>>> http://cr.openjdk.java.net/~never/8155047/webrev <http://cr.openjdk.java.net/~never/8155047/webrev>
>>> 
>>>          public LeafType(ResolvedJavaType context) {
>>> +            assert !context.isLeaf() : "assumption isn't required for leaf types";
>>> This assert is confusing.  The assumption is that a given type has no subtypes, which is also true for leaf types.  Does this assert make sure it’s not used in the wrong places?
>> 
>> LeafType is an assumption that a dynamic type that might someday have subclasses doesn’t currently have any.  isLeaf() is a static guarantee that a type will never have subclasses, so we are asserting that we never emit a dynamic dependence for something that is statically true.  I’m open to new wording.
>> 
>> tom
>> 
>>> 
>>>> 
>>>> findLeafConcreteSubtype should use the same machinery for the elemental type when identifying leaf array types.
>>>> 
>>>> tom
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160512/5f050385/attachment.html>