[drmaa-wg] Re: Java DRMAA: why deleteJobTemplate()

Daniel Templeton Dan.Templeton at Sun.COM
Mon Jun 5 19:26:04 CDT 2006


Ed,

I hear ya.  I struggled with that decision.  I agree that logically, a 
finalizer (the Java term for destructor) makes a lot of sense, 
especially since some (many? most?) implementations won't even worry 
about doing any explicit clean-up.  My reasoning hinged on two important 
points:  1) the initial (and still current) SGE implementation did 
require clean-up, and 2) finalizers are generally a bad idea.  
Finalizers in Java screw up garbage collection because they end up 
taking two or more gc's before they actually get collected.  (The first 
gc calls the finalize() method, and assuming finalize() didn't make 
matters worse, the next gc actually collects the object.)  Because the 
DRMAA specs tend towards inclusivity, the fact that the operation is in 
the DRMAA 1.0 spec and the SGE implementation would need, is enough to 
require it in the spec.

(Another issue that has come up since the spec was initially written is 
how to do a remotable Session interface to a DRMAA library with native 
code.  It that case, it becomes quite a bit easier to simply know that 
your clients will tell you explicitly when they're done with their job 
templates.)

In the case of a pure Java implementation with no funny tricks, the 
deleteJobTemplate() method ends up being essentially empty.  I hold that 
it is within the rights of such an implementation to provide a 
deleteJobTemplate() method, but to declare the use of the method 
unnecessary.  Such a statement would, of course, carry the caveat of 
producing code that is not strictly portable, much like the optional and 
implementation-defined job template properties.

Daniel

Ed Baskerville wrote:
> Hi again,
>
> I'm putting together headers for the Xgrid Objective-C DRMAA 
> interface, and ran into another question for you on Java DRMAA: why do 
> you include a deleteJobTemplate method in the Session interface? As 
> far as I can tell, a JobTemplate is basically just a data structure, 
> so why can't releasing the C struct just get taken care of in the 
> destructor?
>
> My instinct with ObjC is to just put it in the analogous "dealloc" 
> method rather than having an explicit deleteJobTemplate: method in 
> DRMAASession. (In my case, there's not even any C struct to free, 
> since Objective-C is the native implementation for XgridDRMAA.)
>
> --Ed
>





More information about the drmaa-wg mailing list