openjdk9 on Freebsd

Brian Gardner openjdk at getsnappy.com
Thu Mar 17 05:00:40 UTC 2016


Is anyone else interested in getting these changes into the jdk9 mainstream?  It’s been over a month without a response.


> On Feb 15, 2016, at 6:13 PM, Brian Gardner <openjdk at getsnappy.com> wrote:
> 
> Hello,
> I’ve been working on getting jdk9 to build cleanly and compile and run HelloWorld cleanly on Freebsd.  This was following up on a couple patches released by Magnus Ipse Bursie who works at Oracle.  He is interested in getting some of these changes integrated into to jdk9 mainline.
> 
> Here are his patches:
> WebRev for build changes: 
> http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 <http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01> 
> 
> To make this compile properly on BSD, some source code changes are also needed. Here is a simple patch that fixes the compilation show-stoppers. Note that this is *not* part of this bug. 
> http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/ <http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/>
> 
> 
> 
> Here are my patches which supplement Magnus’s:
> 
> porting build_vm_def.sh from bsd-port/jdk8 repo, to fix NM errors during build
> http://brian.timestudybuddy.com/webrev/hotspot__NM/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__NM/webrev/>
> Add SUPPORT_RESERVED_STACK_AREA flag for all BSD's
> http://brian.timestudybuddy.com/webrev/hotspot__SUPPORT_RESERVED_STACK_AREA/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__SUPPORT_RESERVED_STACK_AREA/webrev/>
> porting getthreadid logic from bsd-port/jdk8. calling syscall(SYS_thr_self) caused pthread_setspecific to be cleared.
> http://brian.timestudybuddy.com/webrev/hotspot__os_bsd_cpp__getthreadid/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__os_bsd_cpp__getthreadid/webrev/>
> adding in servicability agent ported from bsd-port/jdk8
> http://brian.timestudybuddy.com/webrev/hotspot__sa/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__sa/webrev/>
> adding classlist.bsd that is identical to classlist.linux, in order to compile
> http://brian.timestudybuddy.com/webrev/jdk__classlist-bsd/webrev/ <http://brian.timestudybuddy.com/webrev/jdk__classlist-bsd/webrev/>
> 
> 
> 
> The next patches where less straightforward.  When running java I was getting a ton of messages like:
> Thread 832744400 has exited with leftover thread-specific data after 4 destructor iterations
> After doing a lot of digging and debugging on Linux, I found the code path for Linux was identical for Freebsd and the cleanup destructor was being executed 4 times just like Freebsd, the difference being that Freebsd would print out this benign warning while Linux would just ignore it.  The problem is that all threads that are created and initialize TLS current thread data, must clean them up by explicitly setting the TLS current thread to null.  I’ve come up with two approaches to accomplish this.
> 
> clean up TLS current thread at end of ::run functions similar to how it's done in openjdk8.
> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/>
> clear current thread before exiting java_start to avoid warnings from leftover pthread_setspecific data
> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/>
> 
> 
> With all these patches I’ve accomplished my initial goal of getting Freebsd to build cleanly and compile and run HelloWorld cleanly on Freebsd
> 
> Thanks,
> Brian Gardner
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160316/803f1bce/attachment-0001.html>


More information about the bsd-port-dev mailing list