please review fix for 4766230: invokevirtual override handling

Karen Kinnear Karen.Kinnear at Sun.COM
Sun Mar 8 17:30:28 PDT 2009


Florian,

Thank you for reading the proposal and asking. As you have read there  
are two changes in
this fix - the first is the assertion/crash, the second is  
invokevirtual override handling.

Since the invokevirtual override handling, despite being a fix to  
match the specification, is
a change in behavior, we are only going to implement it for classfile  
version >= 51 which
is JDK7, so clearly even if the code were in OpenJDK6, that component  
would have
no behavior change.

In terms of the assertion/crash - we explicitly waited for the 6u14  
snapshot to be taken
before putting this change in the source code. Despite extensive  
testing, changes like this
have potential risks and our goal is to shake this out in the JDK7  
repository first, assuming
that (Open)JDK6 is more likely to be used in production environments  
sooner.

One of the key goals of this fix is to lay the groundwork for the jsr  
294 module language changes,
which is exploring adding the concept of module-private to the access  
modes. That is targeted
for JDK7, so we wanted to clean up the underlying mechanism before  
adding another level
of complication.

So, at this point in time, we do not have a target date for OpenJDK6.  
The bug has been in
the system for multiple releases, and with rare exception it is  
difficult to cause the problem if
you use javac. You have to compile a javac consistent set of files,  
and then in at least one, if not multiple
steps, modify subsets of the files and just compile those so that  
javac doesn't notice you are
breaking the rules in changing accessibility. So we do not believe  
that a lot of
customers are running into this problem today.

If that is not accurate and you know of customers that critically need  
this fix sooner, please
let us know.

thank you,
Karen

On Mar 8, 2009, at 5:58 PM, Florian Weimer wrote:

> * Karen Kinnear:
>
>> • Problem 1: in debug: there are cases that assert "index out of
>> bounds", and can crash in product mode.
>
>> • This is because in hotspot, the calculation for vtable size is
>> inconsistent with the calculation for adding vtable entries in the
>> hotspot implementation.
>
> Do you plan to backport this to (Open)JDK 6?  If yes, in what
> timeframe?




More information about the hotspot-runtime-dev mailing list