RFR(xxxs): 8204164: OOM-only logging in Metaspace

Thomas Stüfe thomas.stuefe at gmail.com
Mon Jun 4 05:28:35 UTC 2018


Hi Kirk,

I can see your point. But I always considered the VM-internal logs a
property of the VM developers, which they can reform as they see fit.
What you call "arbitrary" changes are usually done to formulate a
certain sentence clearer to give our support a better handle on
pathological situations. Sometimes also simple aesthetics, e.g. to
unify expressions among multiple log sites.

The problem is that there are no compatibility rules to follow. In all
my years as a VM developer outsiders parsing our traces were always
the bane of our work since it is almost impossible to stay backward
compatible with logging. Since there are no compatibility rules, all
you have is a vague "do not change too much" which is not helpful at
all; if you take it seriously, you cannot change anything since anyone
might complain (even though in reality about 99% of all log output are
really only read by you, but who knows for sure?). You end up
completely paralyzed.

I could see various theoretical solutions to that, but all would
require a larger discussion and some form of compatibility rules to
agree upon.

Best Regards,Thomas


On Mon, Jun 4, 2018 at 7:11 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> Hi David,
>
> I appreciate that. My opinion on logging is that one should expect meaningful changes in the information being logged but hopefully we only see meaningful changes. IOWs, I think we’re on the same page here.
>
> Kind regards,
> Kirk
>
>> On Jun 4, 2018, at 2:23 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kirk,
>>
>> Please note I was simply commenting on the proposal to remove a tag from unified logging - something which will result in a failure to start the VM for anyone currently using that tag.
>>
>> Cheers,
>> David
>>
>> On 2/06/2018 5:39 AM, Kirk Pepperdine wrote:
>>> Hi David,
>>> As you likely know, I’ve bee dealing with changes in GC logging for what feels like forever…. And I support parsing GC logs as far back as the 1.4.2. Bottom line, logs need to change to reflect changes in the implementation…  IME, changes in logs come in two forms, those that add materially to the log and those that are just arbitrary in nature and don’t add any real value. Sometimes even correcting a “not so accurate representation” isn’t enough to actually justify the change. However, when there is real benefits there is no question, the change should be made and I’ll happily adjust my tooling to accommodate. Frustration sets in when the changes are arbitary in that they offer no material change to the information in the logs. This serves only to complicate the parsing of the file. As an example, over the years there have been more than 10 changes in the format to how remark cycles in CMS have been reported yet the information in each of these changes is pretty much the same.
>>> In this case the oom tag may add context that will prove to be useful. As tags are optional in the log, I don’t rely on them but I do use them to add context.
>>> Kind regards,
>>> Kirk
>>>  1, 2018, at 1:22 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> On 1/06/2018 6:37 AM, coleen.phillimore at oracle.com wrote:
>>>>> I agree, this seems good, and fine with me to remove freelist.
>>>>
>>>> Have we established any policy for lifecycle management of logging tags? If you just rip out a tag and someone has a special logging script they run occasionally if they need to gather specific information, then they suddenly get a failure because someone decided "naw don't need that tag".
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Coleen
>>>>> On 5/31/18 3:35 PM, Gerard Ziemski wrote:
>>>>>> hi Thomas,
>>>>>>
>>>>>> Your enhancement looks useful to me.
>>>>>>
>>>>>> Removing “freelist” tag from “metaspace” seems worthy of a separate issue/discussion.
>>>>>>
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>>> On May 31, 2018, at 6:36 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> very tiny improvement. The intent is to be able to restrict metaspace
>>>>>>> logging to OOM situations.
>>>>>>>
>>>>>>> CR: OOM-only logging in Metaspace
>>>>>>> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8204164-oom-only-logging-in-metaspace/webrev.00/webrev/
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> On a related note, would anyone be offended if I were to remove the
>>>>>>> "freelist" logging tag from the metaspace coding? I am not sure that
>>>>>>> is useful in any way.
>>>>>>>
>>>>>>> Thanks, Thomas
>


More information about the hotspot-runtime-dev mailing list