User account creation filtered due to spam.

Bug 22377 - BC compilation fails to detect abstract instantiation
Summary: BC compilation fails to detect abstract instantiation
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Blocks: 12725
  Show dependency treegraph
Reported: 2005-07-08 19:08 UTC by Tom Tromey
Modified: 2016-09-30 22:51 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-07-11 16:26:46


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2005-07-08 19:08:33 UTC
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.
Comment 1 Bryce McKinlay 2005-07-11 15:44:21 UTC
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.

Comment 2 Andrew Pinski 2005-07-11 16:26:45 UTC
Comment 3 Tom Tromey 2006-02-07 18:43:01 UTC
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.
Comment 4 Tom Tromey 2006-03-07 15:16:20 UTC
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.
Comment 5 Paolo Bonzini 2009-02-16 09:23:26 UTC
Just came here by chance :-)

You can check "if (this.class == ...)" in the constructor.  It will slow down constructors for subclasses though.
Comment 6 Tom Tromey 2009-02-22 17:04:23 UTC
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.
Comment 7 Andrew Pinski 2016-09-30 22:51:31 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.