[11] RFR(S): 8199624: [Graal] Blocking jvmci compilations time out

Tobias Hartmann tobias.hartmann at oracle.com
Wed Mar 21 07:09:32 UTC 2018

Thanks, Vladimir!

Best regards,

On 21.03.2018 01:23, Vladimir Kozlov wrote:
> Looks good.
> Thanks,
> Vladimir
> On 3/20/18 7:39 AM, Tobias Hartmann wrote:
>> Forgot to mention that I've also fixed the AbstractMethodErrorTest by changing the to be compiled
>> method name from "c" to "mc" and making the methods public such that they will be found by
>> Class.getMethod(). Before, the test would never find these methods and always bail out through the
>> NoSuchMethodException catch clause.
>> Best regards,
>> Tobias
>> On 20.03.2018 15:35, Tobias Hartmann wrote:
>>> Hi,
>>> please review the following patch:
>>> https://bugs.openjdk.java.net/browse/JDK-8199624
>>> http://cr.openjdk.java.net/~thartmann/8199624/webrev.00/
>>> Multiple tests fail with Graal as JIT and BackgroundCompilation disabled because compilations issued
>>> via WhiteBox.enqueueMethodForCompilation do not block. The problem is that the jvmci compilation may
>>> time out (see CompileBroker::wait_for_jvmci_completion() added by [1]).
>>> I think we want to avoid checking the PrintCompilation output for all tests that trigger a
>>> compilation because that would mean that we need to spawn a separate VM process and verify the
>>> output for all these test. Instead, I suggest to increase the timeout value for blocking jvmci
>>> compilations and change the WhiteBox API to return false in case a blocking compilation does not
>>> block (i.e. times out). We can then catch and ignore the timeout in the affected tests.
>>> I've verified that the timeout value is high enough in most cases (100 runs) and that the tests
>>> still pass in case the jvmci compilation does still time out. More tests might be affected but I
>>> think we should only fix them on demand.
>>> Thanks,
>>> Tobias
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146705

More information about the hotspot-dev mailing list