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