RFR(S): 8027572: assert(r != 0) failed: invalid

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Nov 6 11:10:01 PST 2013



On 11/6/13 9:11 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8027572/webrev.00/
> During profile collection, the first time a type is seen it is recorded in the profile. If a different class is seen later on, the profile code sets the unknown bit but doesn’t clear the recorded type so the code expects that if the unknown bit is set then a type is recorded. When c1 collects the profiles, if some class is already recorded and it knowns the type will differ, it only emits code to set the unknown bit. If the class that is already recorded is unloaded, then the profile is cleared but the c1 code is not changed and so may set the unknown bit in a cleared profile.
> I changed the code so that a class is no longer expected in the profile if the unknown bit is set. When a class recorded in a profile is unloaded the previous code would reset the profile not preserving the null and unknown bit. That doesn’t really make sense so I changed that. Also, there was a bug with parameters for which class unloading wouldn’t be propagated to the profiles and we could end up with an invalid class pointer in the profile.
> Roland.

More information about the hotspot-compiler-dev mailing list