This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question About Unremoved ThreadLocations


On 12/17/2011 11:14 PM, Per Bothner wrote:
It's possible there may be a tradeoff here between avoiding
a potential leak vs caching the needed SharedLocation objects.
But I haven't tried yet to figure out which objects are "leaking".

I think it may be difficult to fix this, at least without changing the semantics of fluid bindings.

The fluid-let bindings are set and restored using the
setWithSave and setRestore methods in ThreadLocation.java.
These cat getLocation, which is where the problem SharedLocation
are allocated.  Note that setRestore does not clear the ThreadLocal
bindings.

It should be possible to "inline" getLocation into setWithSave and setRestore,
in which case setRestore could null out the ThreadLocal which fixes the
immediate problem. But there are two downsides I can think of:


(1) More overhead next time the fluid is set, since we need to re-allocate
the SharedLocation. With the existing code we have the SharedLocation available
for future use.


(2) Others routines, and in particular get, also call getLocation, which
allocates a SharedLocation, and so leads to a potential leak.

The problem could, I think, we solved by just using an InheritableThreadLocal,
as we currently do, but storing the actual value in the ThreadLocal, rather
than indirecting to a SharedLocation. This should also improve performance
quite a bit. The problem is this changes the semantics of fluid variables:
Currently, if a child thread doesn't create a new binding with fluid-let,
it gets the "current" value from the parent. Thus until you do fluid-let,
all threads share the same binding. Using InheritableThreadLocal to store
the actual value means a child threads inherits the value when the child
is created, and does not see updates after that. Which may be a better
sematics - or at least one that is reasonable given the tradeoffs.
--
--Per Bothner
per@bothner.com http://per.bothner.com/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]