6894807: problem with interfaces in C2 type system

John Rose John.Rose at Sun.COM
Mon Oct 26 23:23:33 PDT 2009


On Oct 27, 2009, at 1:39 AM, Vladimir Kozlov wrote:

> So do you agree with Tom suggestion?: return ft if ftkp- 
> >klass_is_exact().

If it fixes the bug, I guess it's OK.  Letting the interface through  
the CastPP (or Phi) can cause other bugs to happen.  (All of these  
bugs come from a flimsy representation of interfaces in Type.)  Some  
of those CastPP guys are standing there to prevent interfaces and  
classes from mixing.

But, in the case of a constant interface TypeKlassPtr, I don't see the  
harm in it.  (Just watch the nightlies!)

It bothers me to break the symmetry between the two cases (inst/ 
klass).  The following change is equivalent (I think) to Tom's  
suggestion, and reads better to me:

    if (ft->empty()) { ... }
  + if (ft->singleton())  return ft;
    // If we have an interface-typed Phi ...

In any case, leave a comment behind with the bug number.  The next  
reader of the code will need lots of help.

-- John

P.S.  My mental picture of Type is that it represents a set of  
assertions.

Type Integer asserts {isa Integer, isa Number, isa Object, isa  
Serializable, isa Comparable}.
Meet is set intersection, while join is set union.
The following sets cannot be represented, but should be IMO:
{isa Serializable, isa Comparable}, {isa Serializable}, {isa Comparable}

(Some assertions can be negated also.  An exact type C:exact asserts {! 
isa D} for every subclass D of C.)

If TypeInstPtr could represent one class plus zero or more interfaces,  
we could (I think) get rid of a lot of this dancing around the snakepit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091027/748e1810/attachment.html 


More information about the hotspot-compiler-dev mailing list