RFR (XS) 8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Aug 29 11:47:46 PDT 2013
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
>>
More information about the hotspot-compiler-dev
mailing list