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
