RFR: 8185525: [Event Request] Add Tracing event for DictionarySizes

[Erik Gahlin]

On 2019-04-10 22:03, gerard ziemski wrote:
>
>
> On 4/10/19 1:12 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> I noticed that events are only emitted if we are able to take the 
>>>> resize lock. Can this be fixed? What prevents us from always 
>>>> getting the data? That's how other periodic events work and losing 
>>>> data sometimes may lead to subtle bugs that hard to understand and 
>>>> replicate in systems that rely on the information. Could we retry 
>>>> on a failure?
>>> Good observation. If the resize lock is taken, then it's not likely 
>>> that whoever owns it will be done soon, so retrying is most likely 
>>> not going to succeed right away. Is it OK to tie up JFR periodic 
>>> thread for some time? If so, how long? 
There is no general upper limit for periodic events.

If we need to wait for a safepoint, we need to do it. That said, events 
that can induce significant latencies or CPU overhead (even in 
pathological cases) are off in default.jfc and only enabled in 
profile.jfr, or not at all.

As I understand it, the events themselves don't cause latencies and the 
tables are not expanded that often, so I think it would be okay to emit 
them.  If you think otherwise, I would try to scan concurrently, even if 
it means we are slightly off.

>>>
>>>
>>> If the lock is taken, then it means that someone is scanning through 
>>> the entire table, or the table is being resized. Either way, we're 
>>> not loosing data, but are just temporarily blind - I don't see a 
>>> problem here for a long running apps, they will start receiving 
>>> events eventually (which happen every 10 sec by default)
A user can set period "everyChunk" which means events are guaranteed to 
be in the recording.

I think we should try to avoid breaking that contract. When event 
streaming is in place, we can implement requestable events where a user 
can demand an event programmatically from Java. If they sometimes don't 
get an event, it will break their code in a subtle way.

Thanks
Erik

>>
>> Robbin was talking about allowing scanning the table while resizing, 
>> ie. not having the resize_lock, if we can accept that there might be 
>> some entries double counted.
>
> Yes, we could do that - are you suggesting that this is what we should 
> do? Personally, I think I'd prefer not to emit the event at all, 
> rather than emit one that might be wrong (that's exactly what we do 
> currently for jcmd print statistics).
>
> Erik, Robbin, do you have a preference here?
>
>
> cheers
>