[Bug java/22377] New: BC compilation fails to detect abstract instantiation

[Bug java/22377] New: BC compilation fails to detect abstract instantiation

[tromey at gcc dot gnu dot org]

Suppose you have bytecode that tries to instantiate an abstract class.
The compiler accepts this (as it ought to), but then at runtime the
instantiation succeeds.  Instead it should throw InstantiationException
(This problem applies to interfaces as well.)

The simplest way to fix this would be to add a check to _Jv_AllocObject
and friends.  However, this may be too expensive (we want to keep allocation
paths short...)

Another approach would be a table of "new pointers", which points to the
allocator for any class instantiated from the current compilation unit.
This could be filled in at link time.

-- 
           Summary: BC compilation fails to detect abstract instantiation
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tromey at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
OtherBugsDependingO 12725
             nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377

[Bug java/22377] BC compilation fails to detect abstract instantiation

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2005-07-11 15:44 -------
There might be a way to implement this without additional _Jv_AllocObject cost
and without adding new ABI tables. 

If abstract classes and interfaces were given a zero or negative value in their
size field, I think the GC will call GC_oom_fn if an attempt were made to
allocate them. We could then throw InstantiationException instead of
OutOfMemoryError in this case.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377

[Bug java/22377] BC compilation fails to detect abstract instantiation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-11 16:26 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-11 16:26:46
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377

[Bug java/22377] BC compilation fails to detect abstract instantiation

[tromey at gcc dot gnu dot org]

------- Comment #6 from tromey at gcc dot gnu dot org  2009-02-22 17:04 -------
I'm not sure that suggestion will work.
My recollection is that the order of checks is specified,
and that allocating memory before the abstract-ness check
would be incorrect.
I didn't confirm this with the spec though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377

[Bug java/22377] BC compilation fails to detect abstract instantiation

[bonzini at gnu dot org]

------- Comment #5 from bonzini at gnu dot org  2009-02-16 09:23 -------
Just came here by chance :-)

You can check "if (this.class == ...)" in the constructor.  It will slow down
constructors for subclasses though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377

[Bug java/22377] BC compilation fails to detect abstract instantiation

[tromey at gcc dot gnu dot org]

------- Comment #4 from tromey at gcc dot gnu dot org  2006-03-07 15:16 -------
Now I think the idea in comment #3 is incorrect.
I looked at implementing it today, and I realized that
it will also cause a super() constructor call to
throw an exception.

The idea in comment #1 may still work.  I'd prefer something
more direct however.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377

[Bug java/22377] BC compilation fails to detect abstract instantiation

[tromey at gcc dot gnu dot org]

------- Comment #3 from tromey at gcc dot gnu dot org  2006-02-07 18:43 -------
Andrew pointed out on irc that we could also implement this by
installing a pointer to a "constructor" which would simply throw
the appropriate exception.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377