hotspot messages about the future?

[David Holmes]

Karen Kinnear said the following on 10/09/10 11:24:
> Yes, the VM is supposed to be invisible, we spent years trying to clean 
> this up.
> 
> Looks like we have a bug?

I assume it is okay to print messages if the selected option causes 
initialization of the VM to fail? And also okay if such messages only 
occur when "logging" and/or "verbose" flags are enabled.

Looking in arguments.cpp we currently have a mix of non-fatal messages, 
some as warning()s and others (like these) just as printfs.

Seems to me we need a consistent policy here on what mechanism to use 
for these kinds of "warnings" and how to control them. That would seem 
to be the warning() function now that Keith is doing a fix to allow 
warnings to be turned on and off.

David

> thanks,
> Karen
> 
> On Oct 8, 2010, at 9:04 PM, John Rose wrote:
> 
>> Absolute silence is a fine ideal.  As long as we are less than ideal, 
>> there's also this:
>>  -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput
>>
>> (Seems a bit odd to have to unlock diagnostics to turn them off, but 
>> there's where it stands today.)
>>
>> And conversely:
>>  -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput
>>
>> -- John
>>
>> On Oct 8, 2010, at 5:21 PM, Kelly O'Hair wrote:
>>
>>> There is  a long list of CRs related to hotspot stdout and stderr 
>>> (start with 4837953).
>>>
>>> The issue I remember is that if I write a java app that uses stdout 
>>> and stderr in it's logic,
>>> and hotspot or the jdk also dumps text to stdout and stderr, it makes 
>>> the java app's stdout/stderr
>>> pretty worthless.
>>>
>>> The java app needs to own stdout and stderr, in my opinion, or at a 
>>> minimum it needs to own stdout.
>>>
>>> I always thought the VM was supposed to be somewhat invisible, the OZ 
>>> guy behind the curtain, unseen
>>> unless something REALLY serious happens.
>>>
>>> -kto
>>>
>>> On Oct 8, 2010, at 4:06 PM, John Pampuch wrote:
>>>
>>>> My recollection is that we choose not to insert messages like this.  
>>>> From my perspective, the output could get really noisy, and spurious 
>>>> output in a release like that *could* affect a shell script, so it 
>>>> could get annoying.
>>>>
>>>> Not sure if I'm completely right on the policy, and even if I am, it 
>>>> probably isn't written down anywhere.  At very least, I don't recall 
>>>> us doing it before (not that I'm in a habit of checking.)
>>>>
>>>> -John
>>>>
>>>> On 10/8/10 3:54 PM, David Holmes wrote:
>>>>> Kelly O'Hair said the following on 10/09/10 05:21:
>>>>>>
>>>>>> When did the  hotspot -XX options start spitting out messages like 
>>>>>> this?
>>>>>
>>>>> I can't tell exactly, but this was there when HS moved to Mercurial.
>>>>>
>>>>> I think it is done whenever an option has become obsolete, or is 
>>>>> not applicable/appropriate for the given usage.
>>>>>
>>>>> David
>>>>>
>>>>>>
>>>>>> svc6<1263> java -XX:+CMSClassUnloadingEnabled 
>>>>>> -XX:+CMSPermGenSweepingEnabled -version
>>>>>> Please use CMSClassUnloadingEnabled in place of 
>>>>>> CMSPermGenSweepingEnabled in the future
>>>>>> java version "1.6.0_10"
>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
>>>>>> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
>>>>>>
>>>>>>
>>>>>> I always thought silence was golden?
>>>>>>
>>>>>> -kto
>>>>>>
>>>
>>
>