[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