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

Tom Rodriguez tom.rodriguez at oracle.com
Thu May 12 20:50:48 UTC 2016


> On May 12, 2016, at 11:34 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On May 12, 2016, at 6:29 AM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>> 
>> So can I considered this reviewed?
> 
> Sorry, yes.

I forgot about it too until Doug pinged me.  Thanks!

tom

> 
>> 
>> 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/5d833f8d/attachment.html>


More information about the hotspot-compiler-dev mailing list