RFR(XS): 8037589: PrintFlagsFinalGetter to testlibrary

[Vladimir Kozlov]

Yes, 8032449 is the right solution.

Thanks,
Vladimir

On 3/18/14 12:28 PM, Igor Ignatyev wrote:
> Vladimir,
>
> I agree w/ you, WB api is better. I've a prototype for such api:
>> template <typename T>
>> bool SetVMFlag(JavaThread* thread, JNIEnv* env, jstring name, T*
>> value, bool (*TAtPut)(const char*, T*, Flag::Flags)) {
>>   if (name == NULL) {
>>     return false;
>>   }
>>   ThreadToNativeFromVM ttnfv(thread);   // can't be in VM when we call
>> JNI
>>   const char* flag_name = env->GetStringUTFChars(name, NULL);
>>   bool result = (*TAtPut)(flag_name, value, Flag::INTERNAL);
>>   env->ReleaseStringUTFChars(name, flag_name);
>>   return result;
>> }
>>
>> WB_ENTRY(jboolean, WB_TestSetBooleanVMFlag(JNIEnv* env, jobject o,
>> jstring name, jboolean value))
>>   bool result = value;
>>   SetVMFlag <bool> (thread, env, name, &result,
>> &CommandLineFlags::boolAtPut);
>>   return result;
>> WB_END
> ...
>
> I am going to integrate it as a part of 8028595.
>
> Lev,
> does WB api work for you? if yes, you can close 8037589 as a dup of
> 8028595/8032449.
>
> Igor
>
> On 03/18/2014 10:53 PM, Vladimir Kozlov wrote:
>> I don't get why you forking new JVM process to get flags value. It is
>> very expensive way to get info.
>> Why not use WB api to get flags values? Current JVM should run already
>> with all flags specified on command line.
>>
>> Thanks,
>> Vladimir
>>
>> On 3/18/14 7:31 AM, Lev Priima wrote:
>>> info from bug description in jbs:
>>> On 03/18/2014 05:58 PM, Igor Ignatyev wrote:
>>>> Lev,
>>>>
>>>> I've uploaded your webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8037589/webrev.00/
>>>>
>>>> What is the common use case for PrintFlagsFinalGetter?
>>> when writing test for java products which does not contain JMX(e.g,
>>> compact1, compact2) we have to read options of VM. Class
>>> com.oracle.java.testlibrary.PrintFlagsFinalGetter may help in testdev
>>> with it
>>>> I don't understand when you need use getFlagsFinal instead of
>>>> getWithVMOpts. So I'd prefer to have one method and use
>>>> ProcessTools::executeTestJvm instead of createJavaProcessBuilder
>>>> Igor
>>>>
>>>> On 03/18/2014 05:35 PM, Lev Priima wrote:
>>>>> Please review and help me with integration:
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037589
>>>>> Webrev: in attachment
>>>>>
>>> Lev