RFR: 8087322: Implement a Semaphore utility class

Stefan Karlsson stefan.karlsson at oracle.com
Mon Jun 15 20:28:50 UTC 2015


Hi again,

I've hopefully addressed some of Kim's and David's concerns with the 
following version:

http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/
http://cr.openjdk.java.net/~stefank/8087322/webrev.01/

Changes in the current version of the patch:

- Created a POSIX version that is used by Linux and Solaris (and maybe 
AIX?).

- Use asserts instead of guarantees. (I've got offline feedback that 
others preferred at least some of the guarantees.)

- Print the errno value and the errno string in the posix version

- Removed trywait and timedwait from the Semaphore class and added that 
functionality in platform-specific semaphore classes. This gets rid of 
the Unimplemented() functions in os_windows.cpp.

- I removed the IMPLEMENTS_SEMAPHORE_CLASS define.

Some comments about the current patch:

- I have not removed the 'max' parameter, since I haven't yet figured 
out what the max value should be used for windows.

- OS X doesn't implement unamed POSIX semaphores, so I have to go 
through hoops to compile out the POXIS version when building on OS X.

- I had to add -lrt to get the patch to link on Solaris.

Tested with JPRT,

Thanks,
StefanK

On 2015-06-12 17:21, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to create a Semaphore utility class. I need 
> this class to implementing faster GC thread synchronization [1].
>
> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8087322
>
> Some of our platforms already implement a Semaphore class, but those 
> classes are hidden inside os_<os>.cpp. I've moved the class 
> declaration to semaphore.hpp, but the implementation is left in the 
> os_<os>.hpp. I considered creating semaphore_<os>.cpp files, but I 
> ended up having to restructure too much code and I wanted to focus on 
> the feature in [1] instead. Should I create a RFE to move the 
> semaphore implementations?
>
> There seems to be another opportunity to cleanup the code. If we take 
> os_linux.cpp, as an example, the code uses both the existing Semaphore 
> class and the global ::sem_wait and ::sem_post functions. We might 
> want to consider unifying that code.
>
> Since HotSpot is built on platforms that I don't have access to and 
> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that 
> I can detect if the the current platform implements the Semaphore 
> class, and choose what synchronization primitive to use by the GC.
>
> The os_bsd.cpp file has support for "non-apple BSD", but I've only 
> tested this patch with OS X.
>
> This patch has been tested in JPRT and our nightly testing together 
> with the patches in [1]. The patch also contains a few unit tests in 
> semaphore.cpp.
>
> Thanks,
> StefanK
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html



More information about the hotspot-dev mailing list