RFR(S): 8240195: some jaotc failures of fastdebug build with specific flags

Liu, Xin xxinliu at amazon.com
Tue Mar 10 05:44:58 UTC 2020


Hi, Roland, 

I tried your patch and I can confirmed that your patch works. 
One cosmetic thing is there're 2 whitespaces in your change of subtypenode.cpp.

It's hard to eyeball those style things in webrev.  Can we use clang-format to enforce C++ coding style? 
I can file a JBS issue and define some basic rules like the position of pointer etc. 

Thanks,
--lx
 

On 3/9/20, 2:11 AM, "hotspot-compiler-dev on behalf of Roland Westrelin" <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of rwestrel at redhat.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
    
    
    
    Correct webrev is:
    
    http://cr.openjdk.java.net/~roland/8240195/webrev.00/
    
    > 8238691 wrongly made all subtype checks with an abstract super class
    > which has no sub class fail. It's only valid if the subclass is loaded
    > from an oop because no oop of an abstract class can be allocated.
    >
    > On an:
    > obj instanceof klass
    > subtype check, the SubTypeCheckNode is created with a direct edge to
    > the obj node.
    >
    > So to distinguish:
    > obj instanceof abstractKlass
    > from:
    > abstractKlass.class.isAssignableFrom(c)
    > all that is needed is to check whether the input to the SubTypeCheckNode
    > is an oop.
    >
    > There's one exception to this, thought. Exception handling sometimes
    > create the following pattern:
    > (SubTypeCheck (LoadKlass obj) ...)
    > which must be transformed to:
    > (SubTypeCheck obj ...)
    > first in order to not miss an constant folding opportunity. I added that
    > transformation in SubTypeCheckNode::Ideal().
    >
    > Roland.
    
    



More information about the hotspot-compiler-dev mailing list