RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance

Tom Schindl tom.schindl at bestsolution.at
Tue Jan 10 12:20:47 UTC 2017


Hi Aleks,

Sorry for not responding but what I tried to say is that with your code
you are still creating a instance of Supplier which could be avoided by
changing the code to use a BiFunction

Take
"src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java"
as a example.

You changed the code to:
---
private static void debugPrintln(Supplier<String> msgGen) {
  if (DEBUG) {
     System.err.println("JAXP: " + msgGen.get());
  }
}

...

debugPrintln(()->"created new instance of " + providerClass +
                    " using ClassLoader: " + cl);
---

If you'd use a BiFunction you would not need to capture "providerClass"
and "cl" hence only one single instance is created.

---
private static void debugPrintln(Object o1, Object o2,
BiFunction<Object,Object,String> msgGen) {
  if (DEBUG) {
     System.err.println("JAXP: " + msgGen.apply(o1,o2));
  }
}

...

debugPrintln(providerClass, cl,
   (o1,o2) ->
     "created new instance of " + o1 + " using ClassLoader: " + o2
);
---

Whether this makes sense depends on how frequently this code is run.

Tom

On 15.12.16 21:45, Aleks Efimov wrote:
> Hi Tom,
> 
> The main purpose of this fix is to postpone debug message string parts
> calculation/concatenation till when the actual output is needed, i.e. we
> don't want to call which(clazz) until the debug output is needed
> (debug=true) in XPathFactoryFinder ). I'm not sure that
> function/bifunction can give us such possibility due to different ways
> of messages construction in dPrint and debugPrintln usages.
> 
> 
> Best,
> Aleksej
> 
> On 15/12/16 20:22, Tom Schindl wrote:
>> Wouldn't it be better to use a function/bifunction instead of a supplier because the supplier is a capturing?
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>> Am 14.12.2016 um 19:04 schrieb Aleks Efimov <aleksej.efimov at oracle.com>:
>>>
>>> Hi Joe,
>>>
>>> Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier<String>' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev:
>>> http://cr.openjdk.java.net/~aefimov/8146271/9/01
>>>
>>> Best Regards,
>>> Aleksej
>>>
>>>
>>>> On 14/12/16 03:35, Joe Wang wrote:
>>>> Hi Aleksej,
>>>>
>>>> You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) where similar problems exist.
>>>>
>>>> Best,
>>>> Joe
>>>>
>>>>> On 12/13/16, 3:02 PM, Aleks Efimov wrote:
>>>>> Hello,
>>>>>
>>>>> Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block:
>>>>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/
>>>>>
>>>>> Best Regards,
>>>>> Aleksej
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271
>>>>>
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck


More information about the core-libs-dev mailing list