harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Lee" <crazy...@crazybob.org>
Subject My first submission! java.lang.ThreadLocal
Date Thu, 05 Jun 2008 23:35:05 GMT
I've addressed two bugs:

https://issues.apache.org/jira/browse/HARMONY-2298
https://issues.apache.org/jira/browse/HARMONY-5703

I attached my patch to the latter. I'm sorry it doesn't build in Harmony out
of the box, but I ran into a compile error in native code and couldn't wait
to submit this. I'm still trying to get acquainted with the Harmony build
but have been impressed by its user friendliness so far.

This ThreadLocal implementation runs as fast and scales as well as the RI. I
ran Doug Lea's own ThreadLocal performance test suite against it.

This impl is particularly memory efficient compared to the RI and it even
cleans up after reclaimed ThreadLocals more aggressively. Here's the memory
break down by thread for N live entries:

RI (educated guesses, obviously not based on looking at their code):

- Table of length L > N
- N entry objects (doubles as weak reference)
 - 4 bytes for array entry in table
 - 28 bytes for entry object
- Expands table when 2/3 full

crazybob's:

- Table of length (L > N) * 2
- 8 bytes per entry
- Expands table when 1/2 full

For a table w/ 16 slots (the default):

One live entry:
RI: 60 bytes/thread
crazybob's: 128 bytes/thread

8 live entries:
RI: 288 bytes/thread
crazybob's: 128 bytes/thread

9 live entries (forces expansion in crazybob's):
RI: 316 bytes/thread
crazybob's: 256 bytes/thread

16 live entries:
RI: 576 bytes/thread
crazybob's: 256 bytes/thread

crazybob's implementation allocates no objects during normal operations, so
there's no allocations and no garbage collection overhead.

Hope you enjoy,
Bob

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message