RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

[Peter Levart]

On 05/20/2015 10:42 AM, Dmitry Samersoff wrote:
> Peter,
>
>> What about creating a special package-private
>> java.lang.ref.DiagnosticCommands class
> I'm not quite happy with current printFinalizationQueue method - love to
> have a way to print directly to DCMD pipe from Java rather than return a
> huge string to VM.
>
> But lang.ref.Finalizer is cached by VM (see
> SystemDictionary::Finalizer_klass()) and is known as special
> i.e. check-when-modify-hotspot class.
>
> We don't plan to expand this DCMD so I'm reluctant to create a separate
> class for one simple static method - it adds extra cost of
> compiling/loading/care.
>
> -Dmitry

Ok then.

I see diagnostic commands mostly format their output in native code. But 
for some of them (like this finalizer histogram) it would be nice to 
have a Java wrapper for hotspot's outputStream. It wouldn't be difficult 
to create such a class with JNI bindings, but where should one put it? 
Into which module?

Otherwise, the simplest unformated data structure to return from such a 
method is an Object[] where you have String/Integer objects intermingled 
in pairs. Returning a Map.Entry<String,int[]>[] is already more 
complicated to iterate and navigate in native code. Map<String,int[]> 
even more so.

Regards, Peter

>
> On 2015-05-20 11:22, Peter Levart wrote:
>>
>> On 05/20/2015 08:51 AM, Dmitry Samersoff wrote:
>>> Mandy,
>>>
>>>> However I have trouble for
>>>> Finalizer.printFinalizationQueue method that doesn’t belong there.
>>>> What are the other alternatives you have explored?
>>> Other alternatives could be to do all hashing/sorting/printing on native
>>> layer i.e. implement printFinalizationQueue inside VM.
>>>
>>> Both options has pros and cons - Java based solution requires less JNI
>>> calls and better readable but takes more memory.
>>>
>>> It might be better to return an array of Map.Entry<String, int[]>
>>> objects to VM rather than one huge string.
>>>
>>> -Dmitry
>> Hi Dmitry,
>>
>> What about creating a special package-private
>> java.lang.ref.DiagnosticCommands class which is then used as the home of
>> static printFinalizationQueue method (and possible future diagnostic
>> commands methods in the package). You could then expose a static
>> package-private method from Finalizer:
>>
>> static void forEachEnqueued(Consumer<? super Reference<?>> action) {
>>      queue.forEach(action);
>> }
>>
>> ...and use it to implement the printFinalizationQueue.
>>
>> Regards, Peter
>>
>>
>>>
>>>
>>> On 2015-05-20 05:54, Mandy Chung wrote:
>>>>> On May 18, 2015, at 5:17 AM, Dmitry Samersoff
>>>>> <dmitry.samersoff at oracle.com <mailto:dmitry.samersoff at oracle.com>>
>>>>> wrote:
>>>>>
>>>>> Please review updated version of the fix:
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.07/
>>>>>
>>>>> Most important part of the fix provided by Peter Levart, so all
>>>>> credentials belongs to him.
>>>> My apology for being late to the review.  The subject line doesn’t catch
>>>> my attention early enough :)
>>>>
>>>> I have to do further detail review tomorrow or so to follow the
>>>> discussion and closely inspect the reference implementation.  Just to
>>>> give you a quick comment.  I’m okay to add ReferenceQueue.forEach method
>>>> at the first glance.  However I have trouble for
>>>> Finalizer.printFinalizationQueue method that doesn’t belong there.  What
>>>> are the other alternatives you have explored?
>>>>
>>>> Mandy
>>>>
>