"Daniel W. Dulitz x108" wrote:
> Rob Clark writes:
> > Here's a crazy idea: the whole problem, as I see it, arises because
> > the JVM's garbage collector only knows of one resource pool, the
> > heap, when in fact there are other resource pools outside the JVM
> > that it should also concern itself with. [...]
> >
> > For example, sun could add to the System class the following method:
> >
> > public static synchronized void incrementResourceUsage
> > (String resourceName, int amount);
> >
> > [...] If a threshold is exceeded, it causes garbage-collection,
> > which will hopefully reduce the amount of the "foobar" resource in
> > use.
>
> I think that would work. But I have three comments. (1) Right now,
> Java has a way to explictly release external resources. You can
> either have a dispose() method in your class and call it at the
> appropriate time (the approach Sun took for graphics-related classes),
> or you can, as Chris suggests, call the finalizer explicitly at the
> appropriate time.
>
If I were sun, I would try and get away from explicitly releasing external
resources because (a) that is an implementation rather than interface issue,
and (b) you have to explicitly do something to release the resources. My
thoughts are that since java aims to be cross-platform, the developer should
not have to know that on some platforms an object may have external
resources associated with it, but not on others. Of course, this is just my
opinion.
>
> (2) incrementResourceUsage() adds a very specialized feature to all
> JVMs, but as you point out, it's difficult to solve all resource
> reclamation problems when using a single-purpose tool like "an
> unweighted integer sum of usage values exceeds a threshhold."
> System.forceGc() would accomplish the same thing much more flexibly:
>
> class ResourceHog {
> // ... whatever stuff you would ordinarily put in ResourceHog
>
> protected static int nInstances = 0;
> protected static final int nMagicInstanceThreshold = 50;
>
> public ResourceHog ( /* whatever */ ) {
> // ... whatever stuff you would ordinarily do
>
> if (++nInstances > nMagicInstanceThreshold) {
> // could also be conditional on other things
> System.forceGc ();
> }
> }
>
> public void finalize () { --nInstances; }
> }
>
> Or you could write a ResourceManager that would do all sorts of cool
> stuff for you.
>
> (3) incrementResourceUsage() would have all the same problems as
> System.forceGc(). In other words, it wouldn't work at all for some GC
> schemes, including conservative GCs. Conservative GCs never know for
> sure that a given reference is live -- they just know when it's dead
> (hence "conservative"). So no conservative GC can ever promise to
> garbage collect all objects that are at that point garbage. (Not to
> mention that "at that point" may be difficult to rigorously define in
> a multithreaded system.)
>
> That's why there is no System.forceGc() in Java, why System.gc() is
> merely a recommendation, and why incrementResourceUsage() is unlikely
> to be implemented.
I think the conservative GC isn't an issue... you have the same problems
whether the resource is allocated from the heap, or from some other resource
pool. All the incrementResourceUsage() does is extend the concept of
resource utilization to other (non-heap) resources, so that they don't go
un-accounted for. You could use the same interface to keep track of % of
heap used (although in implementation you may not want to for performance
reasons).
--
----------------------
Rob Clark
Dot Wireless, Inc.
(858)552-2946
[EMAIL PROTECTED]
----------------------
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
