Peter,
> 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.
I love to have an ability to write pure-java DCMD's without touching of
hotspot code but it's a long term goal, out of scope of this fix.
Just a wrapper around hotspot output stream has a couple of underwear
complications around memory management and error handling, so it should
be a separate project.
-Dmitry
On 2015-05-20 14:44, Peter Levart wrote:
>
>
> 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.samers...@oracle.com <mailto:dmitry.samers...@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
>>>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
