RFR (XS) 8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check

[Vladimir Ivanov]

Done: 8024011: "cleanup: refine Method::(set|is)_not(_c1|_c2)_compilable 
methods" [1]

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8024011

On 8/29/13 10:47 PM, Vladimir Kozlov wrote:
> No, we don't have such RFE. Please, file one.
> Essentially we should have only few positive methods (for example,
> is_compilable()) instead of separate methods for each case.
>
> Thanks,
> Vladimir
>
> On 8/29/13 11:31 AM, Vladimir Ivanov wrote:
>> Vladimir, Chris, thank you for review.
>>
>> Couldn't agree more...
>> Do we already have a RFE for cleanup of this part?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 8/29/13 10:11 PM, Christian Thalinger wrote:
>>> Yes, looks good and yes, it's a mess.  -- Chris
>>>
>>> On Aug 29, 2013, at 9:37 AM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com> wrote:
>>>
>>>> The fix looks good. But this code is a mess.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 8/29/13 8:33 AM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8023976/webrev.00/
>>>>> 18 lines changed: 16 ins; 0 del; 2 mod;
>>>>>
>>>>> This assertion (part of 8022832) doesn't hold for method handle
>>>>> intrinsics (MethodHandle::linkTo*): they should be
>>>>> always "compilable", even if a method is marked as not compilable -
>>>>> there's a special case in Method::is_not_compilable.
>>>>>
>>>>> These methods can be marked as not compilable when, for example,
>>>>> -XX:CompileOnly command is used.
>>>>>
>>>>> There is a discrepancy between Method::is_not_c[12]_compilable() and
>>>>> Method::is_not_compilable(). Instead of changing
>>>>> the assertion, I try to avoid marking MH intrinsics as not compilable.
>>>>>
>>>>> Testing: failing test, HS regression tests.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>