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