harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: My first submission! java.lang.ThreadLocal
Date Fri, 06 Jun 2008 10:16:02 GMT
On Fri, Jun 6, 2008 at 5:00 PM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> Hi Bob, guys!
>
> I had successfully applied Bob's patch for Harmony/DRLVM last night,
> though we need to change java.lang.Thread in luni-kernel. Should we
> discuss this change? Despite the fact my patch defines the same fields
> in java.lang.Thread of DRLVM, this change might break J9+Harmony.
>
> NB: This patch gives 7.6x boost on MTHarness/ThreadLocalBench and +25%
> to SPECjvm2008:serial.

Good numbers! I read the perf is still bad compared to RI? Have you
any estimation about the reason?

I think it's worth to discuss the change to j.l.Thread. Well looking
at the patch, I don't see that's of any issue.

Thanks,
xiaofeng

> Thanks,
> Aleksey.
>
> On Fri, Jun 6, 2008 at 3:35 AM, Bob Lee <crazybob@crazybob.org> wrote:
>> 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
>>
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message