Bug 42493 - Suggest an instrumentable WeakReference variant to help diagnose GC indeterminism bugs
Suggest an instrumentable WeakReference variant to help diagnose GC indetermi...
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: -- Other --
4.x
All All
: P3 (vote)
: TBD
Assigned To: Antonin Nebuzelsky
issues@platform
: API, T9Y
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-27 06:39 UTC by Jesse Glick
Modified: 2013-12-27 16:30 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-04-27 06:39:53 UTC
I just spent a while debugging SourcesHelper,
whose updated test seemed to fail occasionally,
until I realized I was failing to hold a strong
ref to a listener passed to WeakListeners. This
meant (I am guessing) that if GC happened to run
at the wrong time, some critical event would not
get delivered.

I imagine this kind of problem can be frequent; GC
indeterminism can be just as harmful to unit
testing (and code quality) as threading
indeterminism, though easier to fix once you know
what is wrong.

Suggest that a new class be added to
org.openide.util called e.g.
InstrumentableWeakReference, extending
WeakReference, and that all calls to WR's
constructor be replaced with IWR. Its default
behavior would be identical to WR, but you could
set some system properties to control it. In one
mode, it would actually hold a strong reference to
its referent, simulating GC that doesn't happen
soon enough; in another, it would call System.gc
before delegating get() to super, simulating GC
that happens sooner than you expected.

You could set these system properties statically
in tests if you really wanted, or even in the IDE
(slow!), but more usefully NbTestCase could have
some overridable method like

    protected boolean
debugWeakReferenceIndeterminism() {
        return false;
    }

If true, whenever a test method failed, it would
be retried in both of the above modes; according
to the results, it could report the failure with a
special message giving you a hint to check your
weak references. (I.e. you might be assuming that
a weak ref gets collected when it might not be, or
it might be collected when you were not expecting
it to be.)

Sound useful?
Comment 1 Jaroslav Tulach 2004-04-28 14:07:01 UTC
Idea is perfect. Solution not that much.

The best solution would be to instrument
java.lang.reflect.WeakReference itself. Btw. this should be possible
using java.lang.instrument.ClassFileTransformer in 1.5

If we really need support for 1.4, then we could just enhance the
WeakListeners to react to your properties.

Adding new class is an alternative, but only if any of the above
solutions is not going to satisfy our needs.
Comment 2 Jesse Glick 2004-04-28 19:06:04 UTC
Using ClassFileTransformer sounds like a much better idea, nice.
Relying on JDK 1.5 for this purpose is probably fine.
Comment 3 _ rkubacki 2007-10-30 18:08:59 UTC
Mostly performance related. Passing to Petr N.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo