hotspot messages about the future?

[Y. Srinivas Ramakrishna]

Sorry to be late on the discussion. Yes, I see GC's fingerprints on
some of these messages, some rather recent, although I am not sure
we did this first or were just following earlier precedent.

I agree with David. Has a bug been filed?

thanks.
-- ramki

On 10/8/2010 7:00 PM, David Holmes wrote:
> 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
>>>>>>>
>>>>
>>>
>>