invokespecial on abstract method

Sat Oct 4 02:54:00 GMT 2003

Erik Poupaert wrote:
>>>>I'm sure it wouldn't be hard for Sun to make their VM fully evaluate all linkage before running anything, if they wanted to do that. But by design, Java doesn't.
>>>>>>>>>>In terms of optimizing performance/footprints ahead-of-time, is there a cost associated to late linking? I somehow guess there is. 
>Our tests so far have shown that the performance impact of the 
BC-ABI/-findirect-dispatch is somewhere between zero and "minimal". See: 
http://flint.cs.yale.edu/flint/publications/bincomp.html
In terms of resident memory footprint with dynamic linking, I think we 
will be able to do significantly better with the new ABI by reducing the 
amount of data in the shared library that is touched by the linker 
during application startup.
In many ways we will do significantly better than the dynamic linker 
does. Startup time is certainly one, and static method calls will be 
another - the PLT is very inefficient!
>More likely than not, this strategy of late linking may complicate other ongoing efforts that focus on these optimizations.
>>Nope. The BC-ABI will help reduce binary size, resident footprint, and 
startup time. Not the other way around!
>There may be enormous advantages in doing exactly the opposite of what Sun does.
>>I don't think so. Having to recompile all your binaries if you want to 
upgrade to a newwer version of libgcj is an enormous disadvantage. 
Certainly there are situations, like creating a static Java images for 
embedded applications (perhaps against a J2ME "libgcj-lite"), where you 
would want to retain the existing linking model. Like Andrew says, its 
not going away.
Regards,
Bryce