review request (S): 7199082 write warning messages to stderr
David Holmes
david.holmes at oracle.com
Wed Sep 19 00:27:38 PDT 2012
On 19/09/2012 5:11 PM, Staffan Larsen wrote:
> Thanks for clarifying a bit on how tty and VM output works. I've re-read the changes and the source code as well as discussed this with Stefan and Bengt.
>
> There are two (or more) problems here:
>
> 1) VM output should default to stderr. But this should be discussed separately and not as a quick fix to this specific problem. A good timeframe for this could be JDK 8 since it's a major release. I agree with David that we shouldn't special case some of the VM output, it should all go to the same place (unless explicitly changed by the user).
>
> 2) The JDK build fails with the warnings issued for the deprecated permgen flags. Perhaps this is better fixed in the JDK build by either removing the usage of the permgen flags or adding -XX:+DisplayVMOutputToStderr. How doable is that?
Removing the PermGen flags is not quite so simple because it depends on
the version of the boot JDK as to whether or not the flags will be needed.
Adding -XX:+DisplayVMOutputToStderr might be doable.
> It seems to me that we already have a precedent for writing warnings about deprecated flags (the whole obsolete_jvm_flags list) and that the permgen flags are a perfect fit for this list. I think it is reasonable that we should issue warnings in jdk8 and error/abort in jdk9.
My only counter to that is that in my opinion all of the other
deprecated flags are rather obscure and rarely used in practice. In
contrast setting the PermGen sizes is much more common.
I have to ask myself what the value of the warning is compared to the
potential upset it causes for anything that examines stdout or stderr.
If we don't issue a warning and give people time to adjust to the change
then they factor such changes into their systems in a way that suits
them. In contrast if they test JDK8 and find that this warning causes
failures in their environment then they are forced to make changes
before they can even evaluate JDK8.
But as I said in my Review, this can be considered Reviewed as we may
need a quick fix and making this change in the same place as the permgen
changes certainly simplifies things.
Thanks,
David
> Thanks,
> /Staffan
>
>
> On 19 sep 2012, at 07:51, David Holmes<David.Holmes at oracle.com> wrote:
>
>> On 19/09/2012 3:37 PM, Staffan Larsen wrote:
>>> Looks good. All kinds of logging/warning/error messages from the JVM should go to stderr.
>>
>> In which case the correct fix would be to change tty from defaulting to stdout, to default to stderr.
>>
>> When you have a program that runs a program and they share stdout and stderr then you can't always win: no matter where the VM writes to it can interfere with what the app writes. So all hotspot output is nominally sent to 1 place - the tty - and you can then configure the tty to either connect to stdout (the default) or stderr. (And additionally some logging/tracing subsystems allow you to use files to get the VM output out of the picture completely.).
>>
>> Hence I really don't like that we are special casing warnings. :(
>>
>> I think this change will have repercussions, no matter what we try to do to fiddle the output streams, and the issue is whether those repercussions will become known before or after we ship JDK8.
>>
>> My opinion (as I've expressed elsewhere) is that we leave warnings/tty alone and instead we stop issuing the PermGen warnings for JDK8. We can then enable the warnings for JDK9 (and send them to wherever tty sends them) and in JDK10 simply abort if the options are given.
>>
>> David
>>
>>> /Staffan
>>>
>>> On 18 sep 2012, at 20:47, John Coomes<John.Coomes at oracle.com> wrote:
>>>
>>>> Small change to warning() to write to error_stream() instead of tty.
>>>>
>>>> http://cr.openjdk.java.net/~jcoomes/7199082-warn-stderr/
>>>>
>>>> Bug link:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199082
>>>>
>>>> -John
>>>
>
More information about the hotspot-runtime-dev
mailing list