Jeroen Frijters wrote:
No, any VM that implements the spec is vulnerable. Here's an example of a
possible attack:
class Attacker
{
static ArrayListThreadLocal resurrected;
ArrayListThreadLocal list = new ArrayListThreadLocal();
Attacker()
{
for (int i = 0; i 1000; i++)
{
Ian Rogers wrote:
Thanks Jeroen, it's clear now. The problem with a phantom reference is
that when we collect the thread local we should also really make
collectable all of the values set to thread locals. A phantom reference
won't do this and so introduces a memory leak until something can
Ian Rogers wrote:
the attached patch modifies ThreadLocal to use an array of Objects hung
off Thread rather than a weak hash map hung off Thread. On DaCapo's
Jython benchmark this can improve the performance of the Jikes RVM by
more than 10%. It also improves other DaCapo benchmark
Jeroen Frijters wrote:
Ian Rogers wrote:
the attached patch modifies ThreadLocal to use an array of Objects hung
off Thread rather than a weak hash map hung off Thread. On DaCapo's
Jython benchmark this can improve the performance of the Jikes RVM by
more than 10%. It also improves other
Ian Rogers writes:
Jeroen Frijters wrote:
Ian Rogers wrote:
the attached patch modifies ThreadLocal to use an array of Objects hung
off Thread rather than a weak hash map hung off Thread. On DaCapo's
Jython benchmark this can improve the performance of the Jikes RVM by
more
Andrew Haley wrote:
Ian Rogers writes:
Jeroen Frijters wrote:
Ian Rogers wrote:
the attached patch modifies ThreadLocal to use an array of Objects hung
off Thread rather than a weak hash map hung off Thread. On DaCapo's
Jython benchmark this can improve the performance of
Ian Rogers wrote:
One bug in the current implementation is that if the thread local
overrides hashcode and/or equal it can be made to collide with other
thread locals.
No, it uses an Weak*Identity*HashMap.
Regards,
Jeroen
Ian Rogers wrote:
here is the revised patch.
+ int arraySize = group.activeCount();
+ Thread[] threadList = new Thread[arraySize];
+ int filled = group.enumerate(threadList);
+ while (filled == arraySize)
+ {
+arraySize *= 2;
+threadList = new
Jeroen Frijters wrote:
Ian Rogers wrote:
here is the revised patch.
+ int arraySize = group.activeCount();
+ Thread[] threadList = new Thread[arraySize];
+ int filled = group.enumerate(threadList);
+ while (filled == arraySize)
+ {
+arraySize *= 2;
+
Ian Rogers wrote:
How can then the thread local be resurrected after the finalizer is
run?
All the references in ThreadLocal and InheritableThreadLocal are weak
and will be atomically cleared prior to the finalizer being run. All
other references must be dead for the finalizer to have been
Jeroen Frijters wrote:
This is not true. Once an object becomes finalizer reachable the finalizer
can run, but that doesn't mean all references are gone. Any object with a finalizer can
still have references to objects that have already been finalized. In its finalizer it
will be able to
Ian Rogers wrote:
Jeroen Frijters wrote:
This is not true. Once an object becomes finalizer reachable the
finalizer can run, but that doesn't mean all references are gone. Any
object with a finalizer can still have references to objects that
have already been finalized. In its finalizer it
Ian Rogers wrote:
Anyway, this design decision seems to hang off how weak references are
finalized. If they are finalized on their own finalizer thread then the
final local index design is fine and preferable imo to the volatile
design or a weak identity hash map (however cached or stream
13 matches
Mail list logo
