The Runner objects are normally members of a scala singleton object. That way they are constructed once and shared by all the tests.
My understanding is once a singleton object is required, it is constructed, and then never goes away for the life of the JVM (actually the class loader, but those aren't released typically either, so life of the JVM) (per https://stackoverflow.com/questions/3956652/when-are-scala-objects-garbage-collected) So as Runners are usually val or lazy val of these singletons, they will never go out of scope. ________________________________ From: Carlson, Ian <icarl...@owlcyberdefense.com> Sent: Wednesday, October 7, 2020 5:51 PM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: RE: Daffodil-1300 A conversation with Steve Lawrence, and digging deeper into the ThreadLocal aspect of the Runner and DFDLTestSuite objects has called into question whether the shutdown routines are still needed or not. My understanding is that Scala is a garbage collected language, and should dump objects and classes which are no longer in use – so long as references to them are not being held by still-existing objects. The shutdown routine called by the Runner class simply invokes ts_ts.set(null), where tl_ts is of type ThreadLocal[DFDLTestSuite]. Presumably this removes the reference to the DFDLTestSuite and allows it to be garbage collected, but in current cases, the Runner containing the DFDLTestSuite will simply go out of scope once the block of tests is completed. The Runner objects are constructed as lazy val types, so it is my expectation that they will be constructed only when used – as in the TresysTests.scala file – lines 108-181 – and then be released at the end of that scope. So is the invocation of .set(null) on the ThreadLocal[DFDLTestSuite] objects still actually necessary? [A picture containing object, clock Description automatically generated] Ian Carlson | Software Engineer [Owl Cyber Defense] W icarl...@owlcyberdefense.com<https://owlcyberdefense.com/> Connect with us! Facebook<https://www.facebook.com/owlcyberdefense/> | LinkedIn<https://www.linkedin.com/company/owlcyberdefense/> | Twitter<https://twitter.com/owlcyberdefense> [Find us at our next event. Click Here.]<https://owlcyberdefense.com/resources/events/?utm_source=owl-cyber-defense&utm_medium=email&utm_content=banner&utm_campaign=2020-events> The information contained in this transmission is for the personal and confidential use of the individual or entity to which it is addressed. If the reader is not the intended recipient, you are hereby notified that any review, dissemination, or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify the sender immediately From: Beckerle, Mike<mailto:mbecke...@owlcyberdefense.com> Sent: Thursday, October 1, 2020 4:03 PM To: dev@daffodil.apache.org<mailto:dev@daffodil.apache.org> Subject: Re: Daffodil-1300 I think the DFDLTestSuite constructor can't stay deprecated. We still need to construct them. It can become package private I think, so not usable outside the package. I think the scala syntax for that is: class Foo private[pkgName] (arg1: Type1, arg2: Type2) { ... } The deprecation was just to help in hunting down the usages. If we need more Runner functions that's ok. But probably we can just depend on Scala's ability to pass arguments by specifying the argument names explicitly and getting defaults for the rest. I think calls to Runner already do this in many cases. ________________________________ From: Carlson, Ian <icarl...@owlcyberdefense.com> Sent: Thursday, October 1, 2020 4:14 PM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: Daffodil-1300 Regarding DAFFODIL-1300, I’m hunting down usage of “new DFDLTestSuite” and replacing them with usage of the “Runner” object. In order to help identify where the DFDLTestSuite was being invoked, I un-commented: daffodil-tdml-lib/src/main/scala/org/apache/daffodil/tdml/TDMLRunner.scala line 198 @deprecated("2016-12-30", "Use Runner(...) instead." This revealed that the Runner object itself invokes “new DFDLTestSuite” when the runOneTest function is called. This seems to defeat the purpose of this task. I’m hoping for some guidance or opinions on when, if ever, it’s appropriate to invoke the DFDLTestSuite constructor. Related to this – I believe I’ll need to create more constructors for the Runner object in order to preserve the argument combinations currently invoked by some of the new DFDLTestSuite calls – in particular when compileAllTopLevel must be provided as true when paired with an xml node instead of a file name. Is deprecating the DFDLTestSuite constructor still appropriate, or since this ticket was written have we changed or strategy such that it shouldn’t be called directly, but will need to be used by the Runner object? [A picture containing object, clock Description automatically generated] Ian Carlson | Software Engineer [Owl Cyber Defense] W icarl...@owlcyberdefense.com<https://owlcyberdefense.com/> Connect with us! Facebook<https://www.facebook.com/owlcyberdefense/> | LinkedIn<https://www.linkedin.com/company/owlcyberdefense/> | Twitter<https://twitter.com/owlcyberdefense> [Find us at our next event. Click Here.]<https://owlcyberdefense.com/resources/events/?utm_source=owl-cyber-defense&utm_medium=email&utm_content=banner&utm_campaign=2020-events> The information contained in this transmission is for the personal and confidential use of the individual or entity to which it is addressed. If the reader is not the intended recipient, you are hereby notified that any review, dissemination, or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify the sender immediately
