Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Performance hit of Thread.currentThread()

FYI - master is open for 4.7

Am 11.06.2016 8:54 vorm. schrieb "Alex Blewitt" <alex.blewitt@xxxxxxxxx>:

Sent from my iPhat 6
On 11 Jun 2016, at 00:38, Ned Twigg <ned.twigg@xxxxxxxxxxxx> wrote:

This is great to know.  I did some profiling on Win 10, and indeed it does appear that Thread.currentThread() is basically free.

[snip]


Thanks for providing the profiling code. I'm not aware of that particular profiler - the gold standard for profiling is JMH (Tuesday's presentation for the Docklands.LJC is on JMH if you're in London http://docklandsljc.uk/2016/06/hotspot-hood-microbenchmarking-java.html as well as a bit of hotspot intro).

In particular you need to ensure that the compiler doesn't optimise the code away (which may be why it's seeming to be instantaneous). In the code the comparison against the currentThread will likely be removed, since the comparison against null is known to be impossible, and since currentThread has no user visible side effects may be optimised away. 

> There were some patches that were provided but they weren't accepted due to problems with adding new APIs to the builds not being testable.
Is it worth revisiting this?  I'm sure it won't be a 30% performance improvement, since I'd imagine most of the time is getting sunk on the native-code side.  But for code that's doing a lot of java-side stuff, if you could cut the overhead of lightweight calls by 30%, that seems worth grabbing.

The patches were a proof of concept and it wasn't worth updating them because of the fact that the "new API" deadline had passed. It will be worth doing this again for 4.7 once the branches are open again. 

Alex


ᐧ

Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043
340 S Lemon Ave #3433, Walnut, CA 91789

On Thu, Jun 9, 2016 at 3:57 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
I suspect the advice is no longer necessarily correct or has been proven. Although there may be syscalls involved it is certainly the case that the native implementation can be fast-unlined through an intrinsic and it does not have to bail to an interpreter at all. 

https://github.com/dmlloyd/openjdk/blob/2368260acfb88a776d9d759cd1a30f4661e6e195/hotspot/src/share/vm/opto/library_call.cpp#L686

In addition almost all UI updates (including Swing, AWT, and the platforms that SWT supports) require that they be done from the correct thread so this isn't new at all. 

Where it could be optimised is removing the synchronised keyword of the get display thread, and/or add a new method "isDisplayThread()" without synchronisation so that there is less contention for the synchronised block in the Display class itself. There were some patches that were provided but they weren't accepted due to problems with adding new APIs to the builds not being testable. 

Alex

Sent from my iPhat 6

On 9 Jun 2016, at 23:10, Ned Twigg <ned.twigg@xxxxxxxxxxxx> wrote:

Most SWT method calls start with `checkWidget()`, which calls `Thread.currentThread()`.

I haven't profiled it myself, but Lint4j claims that this is an expensive method call:

Has anyone quantified the performance impact of these calls?

An alternative would be to introduce an `@SwtThread` annotation, and use `javaagent` to enable a "debug mode" where the thread is checked, and then not check them at runtime for release builds.

Here is a project which uses a similar approach for Swing:

Just curious if anyone else has looked at this :)

-Ned
ᐧ
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Back to the top