From dalibor.topic at oracle.com Mon Mar 2 13:01:23 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 02 Mar 2015 14:01:23 +0100 Subject: [REMINDER] 2014 OpenJDK Scorecard Survey In-Reply-To: <54EBA988.30604@oracle.com> References: <54EBA988.30604@oracle.com> Message-ID: <54F45F23.4060905@oracle.com> Just a reminder -- please take a few minutes and complete the survey, if you have not already. cheers, dalibor topic On 23.02.2015 23:28, Dalibor Topic wrote: > OpenJDK Discuss Readers, > > You may recall that in 2012 we started[1] the OpenJDK Scorecard to help track the progress of the OpenJDK community in a number of areas. The most recent survey was performed in 2013[2]. The resulting 2013 edition[3] of the OpenJDK Scorecard was published subsequently. > > It's now time for the next edition, covering the 2014 calendar year. > > The scorecard has two parts, a Community Scorecard covering areas related to Infrastructure, Governance and IP; and a Per-Project Scorecard covering Visibility and Technical Matters. The Per-Project Scorecard is for the JDK 9, JDK 8 Updates, JDK 8, JDK 7 Updates and OpenJFX Projects. Other Projects may complete scorecards at their discretion. > > To help track progress, please complete the Community Scorecard first [4], and then the Per-Project Scorecard [5] for each specific project you wish. Please send your feedback no later than 20:00 PDT, Friday, March 6th. > > A big thanks to everyone who participated in the previous editions, and in particular to those who helped draft and review the initial and following scorecards including people from IBM, LJC, Red Hat and SAP. > > cheers, > dalibor topic > > [1] - http://openjdk.java.net/groups/gb/scorecard/2012-09-27.pdf > > [2] - http://mail.openjdk.java.net/pipermail/discuss/2013-October/003179.html > > [3] - http://openjdk.java.net/groups/gb/scorecard/openjdk-scorecard-2013.pdf > > [4] - Link to Community Scorecard (start here): > https://www.surveymonkey.com/r/MX356DX > > [5] - Link to Per-Project Scorecard (Please do this one for at least one Project): > https://www.surveymonkey.com/r/MN82SV8 > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Mar 6 12:50:10 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 06 Mar 2015 13:50:10 +0100 Subject: [FINAL REMINDER] Re: 2014 OpenJDK Scorecard Survey In-Reply-To: <54EBA988.30604@oracle.com> References: <54EBA988.30604@oracle.com> Message-ID: <54F9A282.3030607@oracle.com> Today is the final day left to take part in the 2014 OpenJDK Scorecard Survey, if you have not done so already. cheers, dalibor topic On 23.02.2015 23:28, Dalibor Topic wrote: > OpenJDK Discuss Readers, > > You may recall that in 2012 we started[1] the OpenJDK Scorecard to help track the progress of the OpenJDK community in a number of areas. The most recent survey was performed in 2013[2]. The resulting 2013 edition[3] of the OpenJDK Scorecard was published subsequently. > > It's now time for the next edition, covering the 2014 calendar year. > > The scorecard has two parts, a Community Scorecard covering areas related to Infrastructure, Governance and IP; and a Per-Project Scorecard covering Visibility and Technical Matters. The Per-Project Scorecard is for the JDK 9, JDK 8 Updates, JDK 8, JDK 7 Updates and OpenJFX Projects. Other Projects may complete scorecards at their discretion. > > To help track progress, please complete the Community Scorecard first [4], and then the Per-Project Scorecard [5] for each specific project you wish. Please send your feedback no later than 20:00 PDT, Friday, March 6th. > > A big thanks to everyone who participated in the previous editions, and in particular to those who helped draft and review the initial and following scorecards including people from IBM, LJC, Red Hat and SAP. > > cheers, > dalibor topic > > [1] - http://openjdk.java.net/groups/gb/scorecard/2012-09-27.pdf > > [2] - http://mail.openjdk.java.net/pipermail/discuss/2013-October/003179.html > > [3] - http://openjdk.java.net/groups/gb/scorecard/openjdk-scorecard-2013.pdf > > [4] - Link to Community Scorecard (start here): > https://www.surveymonkey.com/r/MX356DX > > [5] - Link to Per-Project Scorecard (Please do this one for at least one Project): > https://www.surveymonkey.com/r/MN82SV8 > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From jiri.peinlich at ingg.com Thu Mar 19 10:18:44 2015 From: jiri.peinlich at ingg.com (Jiri Peinlich) Date: Thu, 19 Mar 2015 10:18:44 +0000 Subject: JNI calling wrong method Message-ID: <96DD6D5EB224D2419E81EF81E4D9C379082BB984@EX2K10MBX1.ad.london.inspiredbroadcast.net> Hello, we have a java application that calls a native method from a dll. This works for us most of the time but very rarely on some Pcs the JNI is calling wrong native method. As we have finally a machine that reproduces the issue regularly we would like to investigate what is the reason and hopefully fix it, but we are out of ideas how to investigate the issue. I attached a java crash dump. It is visible there that we are trying to invoke method "setVolumeNative". The method "create" is invoked however. We would expect to see the following on stack: Java_net_inspiredbroadcast_legion_jni_volume_MainVolume_setVolumeNative But we see there this: Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create How should we investigate this issue? Thx, Jiri From jiri.peinlich at ingg.com Thu Mar 19 10:22:20 2015 From: jiri.peinlich at ingg.com (Jiri Peinlich) Date: Thu, 19 Mar 2015 10:22:20 +0000 Subject: JNI calling wrong method In-Reply-To: <96DD6D5EB224D2419E81EF81E4D9C379082BB984@EX2K10MBX1.ad.london.inspiredbroadcast.net> References: <96DD6D5EB224D2419E81EF81E4D9C379082BB984@EX2K10MBX1.ad.london.inspiredbroadcast.net> Message-ID: <96DD6D5EB224D2419E81EF81E4D9C379082BC9A0@EX2K10MBX1.ad.london.inspiredbroadcast.net> Hello, we have a java application that calls a native method from a dll. This works for us most of the time but very rarely on some Pcs the JNI is calling wrong native method. As we have finally a machine that reproduces the issue regularly we would like to investigate what is the reason and hopefully fix it, but we are out of ideas how to investigate the issue. Bellow you can see a java crash dump. It is visible there that we are trying to invoke method "setVolumeNative". The method "create" is invoked however. We would expect to see the following on stack: Java_net_inspiredbroadcast_legion_jni_volume_MainVolume_setVolumeNative But we see there this: Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create How should we investigate this issue? Thx, Jiri # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6294c518, pid=14900, tid=7008 # # JRE version: 7.0 # Java VM: OpenJDK Client VM (22.0-b10 mixed mode windows-x86 ) # Problematic frame: # C [common-win32-native-1.0.6-SNAPSHOT.dll+0xc518] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x11969c00): JavaThread "Bootstrap" [_thread_in_native, id=7008, stack(0x12890000,0x128e0000)] siginfo: ExceptionCode=0xc0000005, reading address 0x00000000 Registers: EAX=0x00000000, EBX=0x0d3871c0, ECX=0x730a3130, EDX=0x128df744 ESP=0x128df730, EBP=0x128df754, ESI=0x0d3871c0, EDI=0x11969c00 EIP=0x6294c518, EFLAGS=0x00010247 Top of Stack: (sp=0x128df730) 0x128df730: 6299f488 00000001 00000000 128df744 0x128df740: 00000001 00000000 80070490 00000000 0x128df750: 00000000 128df788 6294bb31 11969d28 0x128df760: 128df7c4 00000000 00000006 00000008 0x128df770: 11969c00 0d3871c0 0d3871c0 128df7bc 0x128df780: 0245a4b7 00969c00 128df7bc 0245a5b7 0x128df790: 11969d28 128df7c4 00000000 128df79c 0x128df7a0: 0d3871c0 128df7cc 0d387920 00000000 Instructions: (pc=0x6294c518) 0x6294c4f8: ff d1 c7 45 fc 00 00 00 00 c7 45 f0 00 00 00 00 0x6294c508: 8d 55 f0 52 6a 00 6a 01 68 88 f4 99 62 8b 45 f8 0x6294c518: 8b 08 8b 55 f8 52 8b 41 0c ff d0 89 45 f4 83 7d 0x6294c528: f4 00 74 16 68 70 f1 99 62 68 90 f1 99 62 8b 4d Register to memory mapping: EAX=0x00000000 is an unknown value EBX=0x0d3871c0 is an oop {method} - klass: {other class} ECX=0x730a3130 is an unknown value EDX=0x128df744 is pointing into the stack for thread: 0x11969c00 ESP=0x128df730 is pointing into the stack for thread: 0x11969c00 EBP=0x128df754 is pointing into the stack for thread: 0x11969c00 ESI=0x0d3871c0 is an oop {method} - klass: {other class} EDI=0x11969c00 is a thread Stack: [0x12890000,0x128e0000], sp=0x128df730, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [common-win32-native-1.0.6-SNAPSHOT.dll+0xc518] Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0xa410 C [common-win32-native-1.0.6-SNAPSHOT.dll+0xbb31] Java_net_inspiredbroadcast_legion_jni_process_ProcessImpl_create+0x9a29 j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolumeNative(I)V+0 j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolume(I)V+49 j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.setVolume(I)V+100 j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.startUp()V+49 j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceLoaderImpl.()V+210 j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceHandler.initialise()V+176 j net.inspiredbroadcast.legion.ikernel.core.BootstrapDelegate.start()Ljava/lang/Integer;+318 j net.inspiredbroadcast.legion.ikernel.core.Bootstrap.start([Ljava/lang/String;)Ljava/lang/Integer;+14 j org.tanukisoftware.wrapper.WrapperManager$11.run()V+75 v ~StubRoutines::call_stub V [jvm.dll+0x1233ba] V [jvm.dll+0x1c8f7e] V [jvm.dll+0x1235a3] V [jvm.dll+0x123607] V [jvm.dll+0xcd1ef] V [jvm.dll+0x1430af] V [jvm.dll+0x1711e9] C [msvcr100.dll+0x10fac] freefls+0x130 C [msvcr100.dll+0x110b1] __fls_getvalue+0x58 C [kernel32.dll+0x133aa] BaseThreadInitThunk+0x12 C [ntdll.dll+0x3bf32] RtlInitializeExceptionChain+0x63 C [ntdll.dll+0x3bf05] RtlInitializeExceptionChain+0x36 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolumeNative(I)V+0 j net.inspiredbroadcast.legion.jni.volume.MainVolume.setVolume(I)V+49 j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.setVolume(I)V+100 j net.inspiredbroadcast.legion.peripheral.win32.MainSystemVolume.startUp()V+49 j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceLoaderImpl.()V+210 j net.inspiredbroadcast.legion.ikernel.service.impl.ServiceHandler.initialise()V+176 j net.inspiredbroadcast.legion.ikernel.core.BootstrapDelegate.start()Ljava/lang/Integer;+318 j net.inspiredbroadcast.legion.ikernel.core.Bootstrap.start([Ljava/lang/String;)Ljava/lang/Integer;+14 j org.tanukisoftware.wrapper.WrapperManager$11.run()V+75 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x11e76c00 JavaThread "CashHandlingWorker" daemon [_thread_blocked, id=5732, stack(0x18e60000,0x18eb0000)] 0x11e76800 JavaThread "Swing-Shell" daemon [_thread_blocked, id=15856, stack(0x13220000,0x13270000)] 0x11e76000 JavaThread "NetConn Monitor" daemon [_thread_blocked, id=15932, stack(0x18560000,0x185b0000)] 0x11c02800 JavaThread "AudioPlayerThread" [_thread_blocked, id=15000, stack(0x18b90000,0x18be0000)] 0x11c02000 JavaThread "D3D Screen Updater" daemon [_thread_blocked, id=14308, stack(0x185d0000,0x18620000)] 0x11c01c00 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=8760, stack(0x17860000,0x178b0000)] 0x11c01400 JavaThread "AWT-Windows" daemon [_thread_in_native, id=12852, stack(0x13280000,0x132d0000)] 0x11c01000 JavaThread "AWT-Shutdown" [_thread_blocked, id=7156, stack(0x12f70000,0x12fc0000)] 0x11c00800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=16016, stack(0x12840000,0x12890000)] 0x11c00000 JavaThread "TelnetServer" [_thread_in_native, id=6376, stack(0x12ed0000,0x12f20000)] 0x11bffc00 JavaThread "EventWorker" daemon [_thread_blocked, id=14384, stack(0x12280000,0x122d0000)] 0x11bff000 JavaThread "ScheduleHandler" daemon [_thread_blocked, id=15584, stack(0x13050000,0x130a0000)] 0x11a21400 JavaThread "MarimbaDownloadStatusMessenger" [_thread_blocked, id=10380, stack(0x113e0000,0x11430000)] 0x11a06c00 JavaThread "MetersWorkingThread" [_thread_blocked, id=7028, stack(0x10d00000,0x10d50000)] 0x119e4800 JavaThread "SuspensionEvaluatorDaemon" daemon [_thread_blocked, id=12132, stack(0x12690000,0x126e0000)] 0x119e3000 JavaThread "Announcer" daemon [_thread_blocked, id=12116, stack(0x129f0000,0x12a40000)] 0x119e2800 JavaThread "Asyncmessage sending thread" [_thread_blocked, id=16036, stack(0x125f0000,0x12640000)] =>0x11969c00 JavaThread "Bootstrap" [_thread_in_native, id=7008, stack(0x12890000,0x128e0000)] 0x009adc00 JavaThread "DestroyJavaVM" [_thread_blocked, id=14360, stack(0x00b20000,0x00b70000)] 0x1192bc00 JavaThread "Wrapper-Connection" daemon [_thread_in_native, id=15560, stack(0x12640000,0x12690000)] 0x118f9c00 JavaThread "Wrapper-Startup-Runner" [_thread_blocked, id=9208, stack(0x12760000,0x127b0000)] 0x11918c00 JavaThread "Wrapper-Control-Event-Monitor" daemon [_thread_blocked, id=15772, stack(0x12700000,0x12750000)] 0x118c9400 JavaThread "Cerberus 1" daemon [_thread_blocked, id=10816, stack(0x12330000,0x12380000)] 0x11325000 JavaThread "ProcessHandler" daemon [_thread_blocked, id=14040, stack(0x11430000,0x11480000)] 0x10529800 JavaThread "Service Thread" daemon [_thread_blocked, id=11748, stack(0x10ad0000,0x10b20000)] 0x10525000 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=11232, stack(0x10bc0000,0x10c10000)] 0x10523c00 JavaThread "Attach Listener" daemon [_thread_blocked, id=16228, stack(0x106f0000,0x10740000)] 0x10522c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=10324, stack(0x10b20000,0x10b70000)] 0x104ca000 JavaThread "Finalizer" daemon [_thread_blocked, id=11864, stack(0x109d0000,0x10a20000)] 0x104c4000 JavaThread "Reference Handler" daemon [_thread_blocked, id=15388, stack(0x10a30000,0x10a80000)] Other Threads: 0x00aff800 VMThread [stack: 0x10760000,0x107b0000] [id=15344] 0x1053d400 WatcherThread [stack: 0x10f10000,0x10f60000] [id=10968] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 4928K, used 718K [0x04450000, 0x049a0000, 0x06ef0000) eden space 4416K, 9% used [0x04450000, 0x044bda98, 0x048a0000) from space 512K, 54% used [0x04920000, 0x04966020, 0x049a0000) to space 512K, 0% used [0x048a0000, 0x048a0000, 0x04920000) tenured generation total 10944K, used 6794K [0x06ef0000, 0x079a0000, 0x0c450000) the space 10944K, 62% used [0x06ef0000, 0x07592988, 0x07592a00, 0x079a0000) compacting perm gen total 15616K, used 15582K [0x0c450000, 0x0d390000, 0x10450000) the space 15616K, 99% used [0x0c450000, 0x0d387a40, 0x0d387c00, 0x0d390000) No shared spaces configured. Code Cache [0x02450000, 0x02638000, 0x04450000) total_blobs=1078 nmethods=832 adapters=182 free_code_cache=30832Kb largest_free_block=31570240 Dynamic libraries: 0x00bf0000 - 0x00c1c000 C:\ikernel\dist\openjdk7\bin\java.exe 0x77900000 - 0x77a80000 C:\Windows\SysWOW64\ntdll.dll 0x767e0000 - 0x768f0000 C:\Windows\syswow64\kernel32.dll 0x76790000 - 0x767d7000 C:\Windows\syswow64\KERNELBASE.dll 0x766f0000 - 0x76790000 C:\Windows\syswow64\ADVAPI32.dll 0x75870000 - 0x7591c000 C:\Windows\syswow64\msvcrt.dll 0x774e0000 - 0x774f9000 C:\Windows\SysWOW64\sechost.dll 0x76600000 - 0x766f0000 C:\Windows\syswow64\RPCRT4.dll 0x75320000 - 0x75380000 C:\Windows\syswow64\SspiCli.dll 0x75310000 - 0x7531c000 C:\Windows\syswow64\CRYPTBASE.dll 0x76cc0000 - 0x76dc0000 C:\Windows\syswow64\USER32.dll 0x772a0000 - 0x77330000 C:\Windows\syswow64\GDI32.dll 0x76cb0000 - 0x76cba000 C:\Windows\syswow64\LPK.dll 0x769d0000 - 0x76a6d000 C:\Windows\syswow64\USP10.dll 0x71020000 - 0x711be000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll 0x77460000 - 0x774b7000 C:\Windows\syswow64\SHLWAPI.dll 0x76570000 - 0x765d0000 C:\Windows\system32\IMM32.DLL 0x76fd0000 - 0x7709c000 C:\Windows\syswow64\MSCTF.dll 0x68000000 - 0x68036000 C:\Windows\system32\QIPCAP.DLL 0x76920000 - 0x769af000 C:\Windows\syswow64\OLEAUT32.dll 0x76b50000 - 0x76cac000 C:\Windows\syswow64\ole32.dll 0x622b0000 - 0x6236d000 C:\ikernel\dist\openjdk7\bin\msvcr100.dll 0x5a810000 - 0x5ab36000 C:\ikernel\dist\openjdk7\bin\client\jvm.dll 0x740a0000 - 0x740d2000 C:\Windows\system32\WINMM.dll 0x769b0000 - 0x769b5000 C:\Windows\syswow64\PSAPI.DLL 0x71620000 - 0x7162c000 C:\ikernel\dist\openjdk7\bin\verify.dll 0x645e0000 - 0x64600000 C:\ikernel\dist\openjdk7\bin\java.dll 0x64580000 - 0x64593000 C:\ikernel\dist\openjdk7\bin\zip.dll 0x64320000 - 0x64334000 C:\ikernel\dist\openjdk7\bin\net.dll 0x770a0000 - 0x770d5000 C:\Windows\syswow64\WS2_32.dll 0x77330000 - 0x77336000 C:\Windows\syswow64\NSI.dll 0x744b0000 - 0x744ec000 C:\Windows\system32\mswsock.dll 0x71ba0000 - 0x71ba6000 C:\Windows\System32\wship6.dll 0x718f0000 - 0x718ff000 C:\ikernel\dist\openjdk7\bin\nio.dll 0x74190000 - 0x741a6000 C:\Windows\system32\CRYPTSP.dll 0x74150000 - 0x7418b000 C:\Windows\system32\rsaenh.dll 0x72160000 - 0x72177000 C:\Windows\system32\USERENV.dll 0x73cc0000 - 0x73ccb000 C:\Windows\system32\profapi.dll 0x742f0000 - 0x74300000 C:\Windows\system32\NLAapi.dll 0x742e0000 - 0x742f0000 C:\Windows\system32\napinsp.dll 0x742c0000 - 0x742d2000 C:\Windows\system32\pnrpnsp.dll 0x74270000 - 0x742b4000 C:\Windows\system32\DNSAPI.dll 0x74260000 - 0x74268000 C:\Windows\System32\winrnr.dll 0x74250000 - 0x7425d000 C:\Windows\system32\wshbth.dll 0x645b0000 - 0x645d7000 C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL 0x74560000 - 0x7457c000 C:\Windows\system32\IPHLPAPI.DLL 0x74550000 - 0x74557000 C:\Windows\system32\WINNSI.DLL 0x74210000 - 0x74248000 C:\Windows\System32\fwpuclnt.dll 0x74200000 - 0x74206000 C:\Windows\system32\rasadhlp.dll 0x71610000 - 0x7161a000 C:\ikernel\dist\openjdk7\bin\management.dll 0x10c10000 - 0x10c5e000 C:\ikernel\dist\lib\wrapper.dll 0x744a0000 - 0x744a5000 C:\Windows\System32\wshtcpip.dll 0x62940000 - 0x629bd000 C:\ikernel\dist\lib\common-win32-native-1.0.6-SNAPSHOT.dll 0x73690000 - 0x73699000 C:\Windows\system32\HID.DLL 0x770e0000 - 0x7727d000 C:\Windows\syswow64\SETUPAPI.dll 0x76fa0000 - 0x76fc7000 C:\Windows\syswow64\CFGMGR32.dll 0x77280000 - 0x77292000 C:\Windows\syswow64\DEVOBJ.dll 0x75920000 - 0x7656b000 C:\Windows\syswow64\SHELL32.dll 0x64060000 - 0x64158000 C:\Windows\system32\CRYPTUI.dll 0x755a0000 - 0x756bd000 C:\Windows\syswow64\CRYPT32.dll 0x75730000 - 0x7573c000 C:\Windows\syswow64\MSASN1.dll 0x768f0000 - 0x7691d000 C:\Windows\syswow64\WINTRUST.dll 0x741e0000 - 0x741f2000 C:\Windows\system32\dhcpcsvc.DLL 0x73910000 - 0x7391d000 C:\Windows\system32\dhcpcsvc6.DLL 0x751b0000 - 0x751d1000 C:\Windows\system32\ntmarta.dll 0x76b00000 - 0x76b45000 C:\Windows\syswow64\WLDAP32.dll 0x731a0000 - 0x731b2000 C:\Windows\system32\SAMLIB.dll 0x72f50000 - 0x72f72000 C:\Windows\system32\logoncli.dll 0x74330000 - 0x74339000 C:\Windows\system32\netutils.dll 0x5e750000 - 0x5e891000 C:\ikernel\dist\openjdk7\bin\awt.dll 0x721a0000 - 0x72220000 C:\Windows\system32\uxtheme.dll 0x73010000 - 0x73068000 C:\Program Files (x86)\Common Files\microsoft shared\ink\tiptsf.dll 0x75240000 - 0x75249000 C:\Windows\system32\version.dll 0x73e30000 - 0x73e43000 C:\Windows\system32\dwmapi.dll 0x70600000 - 0x707c3000 C:\Windows\system32\d3d9.dll 0x72f40000 - 0x72f46000 C:\Windows\system32\d3d8thk.dll 0x69130000 - 0x69f98000 C:\Windows\system32\nvd3dum.dll 0x72a80000 - 0x72aa5000 C:\Windows\system32\powrprof.dll 0x628d0000 - 0x6293d000 C:\ikernel\dist\openjdk7\bin\freetype.dll 0x602c0000 - 0x60345000 C:\ikernel\dist\openjdk7\bin\fontmanager.dll 0x76a70000 - 0x76af3000 C:\Windows\syswow64\CLBCatQ.DLL 0x737a0000 - 0x737dc000 C:\Windows\system32\oleacc.dll 0x70ed0000 - 0x71000000 C:\Windows\system32\WindowsCodecs.dll 0x744f0000 - 0x7453c000 C:\Windows\system32\apphelp.dll 0x637b0000 - 0x637c2000 C:\Program Files (x86)\Common Files\TortoiseOverlays\TortoiseOverlays.dll 0x72ac0000 - 0x72ad4000 C:\Program Files\TortoiseSVN\bin\TortoiseStub32.dll 0x63740000 - 0x637b0000 C:\Program Files\TortoiseSVN\bin\TortoiseSVN32.dll 0x76dd0000 - 0x76f94000 C:\Windows\syswow64\WININET.dll 0x756c0000 - 0x756c4000 C:\Windows\syswow64\api-ms-win-downlevel-user32-l1-1-0.dll 0x774d0000 - 0x774d4000 C:\Windows\syswow64\api-ms-win-downlevel-shlwapi-l1-1-0.dll 0x77340000 - 0x77344000 C:\Windows\syswow64\api-ms-win-downlevel-version-l1-1-0.dll 0x76dc0000 - 0x76dc3000 C:\Windows\syswow64\api-ms-win-downlevel-normaliz-l1-1-0.dll 0x774c0000 - 0x774c3000 C:\Windows\syswow64\normaliz.DLL 0x75380000 - 0x75595000 C:\Windows\syswow64\iertutil.dll 0x778d0000 - 0x778d5000 C:\Windows\syswow64\api-ms-win-downlevel-advapi32-l1-1-0.dll 0x633d0000 - 0x63735000 C:\Program Files\TortoiseSVN\bin\libsvn_tsvn32.dll 0x633a0000 - 0x633c7000 C:\Program Files\TortoiseSVN\bin\libapr_tsvn32.dll 0x632c0000 - 0x63396000 C:\Windows\system32\MSVCR110.dll 0x63280000 - 0x632b8000 C:\Program Files\TortoiseSVN\bin\libaprutil_tsvn32.dll 0x63fe0000 - 0x63fed000 C:\Program Files\TortoiseSVN\bin\intl3_tsvn32.dll 0x63260000 - 0x63273000 C:\Program Files\TortoiseSVN\bin\libsasl32.dll 0x72190000 - 0x72198000 C:\Windows\system32\Secur32.dll 0x631d0000 - 0x63255000 C:\Windows\system32\MSVCP110.dll 0x63150000 - 0x63181000 C:\Windows\system32\EhStorShell.dll 0x71410000 - 0x71505000 C:\Windows\system32\PROPSYS.dll 0x71e00000 - 0x71e70000 C:\Windows\system32\ntshrui.dll 0x74310000 - 0x74329000 C:\Windows\system32\srvcli.dll 0x741d0000 - 0x741db000 C:\Windows\system32\cscapi.dll 0x72b60000 - 0x72b6a000 C:\Windows\system32\slc.dll 0x73990000 - 0x73a14000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll 0x6f950000 - 0x6fae8000 C:\Windows\system32\NetworkExplorer.dll 0x726a0000 - 0x726ce000 C:\Windows\System32\shdocvw.dll 0x741b0000 - 0x741c2000 C:\Windows\system32\MPR.dll 0x71980000 - 0x71988000 C:\Windows\System32\drprov.dll 0x73e70000 - 0x73e99000 C:\Windows\System32\WINSTA.dll 0x71920000 - 0x71934000 C:\Windows\System32\ntlanman.dll 0x73780000 - 0x73798000 C:\Windows\System32\davclnt.dll 0x73800000 - 0x73808000 C:\Windows\System32\DAVHLPR.dll 0x74300000 - 0x7430f000 C:\Windows\system32\wkscli.dll 0x5dc80000 - 0x5deb8000 C:\Windows\system32\wpdshext.dll 0x72ba0000 - 0x72d30000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80\gdiplus.dll 0x60750000 - 0x607d9000 C:\Windows\system32\PortableDeviceApi.dll 0x64370000 - 0x6439b000 C:\Windows\system32\PortableDeviceTypes.dll 0x62270000 - 0x622af000 C:\Windows\system32\audiodev.dll 0x5d5b0000 - 0x5d817000 C:\Windows\system32\WMVCore.DLL 0x642e0000 - 0x6431d000 C:\Windows\system32\WMASF.DLL 0x64340000 - 0x64362000 C:\Windows\system32\EhStorAPI.dll 0x73070000 - 0x730a9000 C:\Windows\System32\MMDevApi.dll VM Arguments: jvm_args: -Djava.security.auth.login.config=jaas.config -Djava.net.preferIPv4Stack=true -XX:-UseSplitVerifier -Dfile.encoding=Cp1252 -Duser.language=en -Xmx128m -Djava.library.path=../lib/patch;../lib/level3;../lib/level2;../lib/level1;../lib;. -Dwrapper.key=dxgPdptyCLpDE9FBk2w3wf_1tGFfWs7N -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=14920 -Dwrapper.version=3.5.15-st -Dwrapper.native_library=wrapper -Dwrapper.cpu.timeout=180 -Dwrapper.jvmid=2 -Dwrapper.lang.domain=wrapper java_command: net.inspiredbroadcast.legion.ikernel.core.Bootstrap Launcher Type: SUN_STANDARD Environment Variables: PATH=C:\ikernel\dist\lib;C:\ikernel\dist\lib;C:\ikernel\dist\bin\\..\lib USERNAME=redacted OS=Windows_NT PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel --------------- S Y S T E M --------------- OS: Windows 7 , 64 bit Build 7601 Service Pack 1 CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht Memory: 4k page, physical 4166716k(1004748k free), swap 8331576k(2764928k free) vm_info: OpenJDK Client VM (22.0-b10) for windows-x86 JRE (1.7.0-INGG-administrator_2012_03_05_18_26-b00), built on Mar 5 2012 18:48:09 by "Administrator" with unknown MS VC++:1600 time: Tue Mar 17 14:39:08 2015 elapsed time: 3 seconds From roman at kennke.org Tue Mar 24 21:45:06 2015 From: roman at kennke.org (Roman Kennke) Date: Tue, 24 Mar 2015 22:45:06 +0100 Subject: Project proposal: Shenandoah In-Reply-To: <54F22501.8050304@oracle.com> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> Message-ID: <1427233506.2642.24.camel@kennke.org> Hi Jon and all, According to http://openjdk.java.net/projects/#new-project we need a Hotspot group lead to declare to sponsor the project: "At least one Group Lead must declare that their Group is a sponsor of the proposed Project." John Coomes (in CC) is the only Hotspot lead, as far as I can see. John, do you think the Hotspot group could sponsor the Shenandoah project? I don't see any other group that would make sense as sponsor. I'd like to put this up for voting as soon as I've got the ok from John Coomes. Thanks, Roman Am Samstag, den 28.02.2015, 12:28 -0800 schrieb Jon Masamitsu: > Roman, > > Thank you for the further information. This large a contribution > is new territory for us so we'll be taking a bit of time to mull it > over. > > Jon > > On 2/28/2015 5:01 AM, Roman Kennke wrote: > > Hi Jon, > > > >>> Shenandoah is developed and maintained by Red Hat, yes, but the > >>> intention is, and has always been, to integrate it into upstream > >>> Hotspot, if OpenJDK people think it's feasible. The first step in this > >>> direction is the creation of a Shenandoah project (this proposal) and we > >>> also want to move forward with the Shenandoah JEP 189. > >> I would also like to understand how an integration of Shenandoah into > >> Hotspot would affect my day-to-day work. For example if I build Hotspot > >> will I skip the build of Shenandoah sources by default? > > Build-wise Shenandoah is a GC like all other GCs. When you build > > Hotspot, you build Shenandoah. It will be excluded by setting > > INCLUDE_ALL_GCS to false, iirc. We could add a build flag to exclude > > Shenandoah, but I don't really see the point of it. > > > > Shenandoah is a bit special because it requires read and write barriers > > in the interpreter, C1, C2 and the runtime. We tried as much as possible > > to make this a clean interface, such to avoid scattering Shenandoah code > > all over the place. One of our goals is to not impact performance or > > behaviour with any other GC. If any other GC in the future requires > > similar barriers, it could just implement those interfaces. It is not > > perfect yet and needs some cleanup. > > > > All that being said, the intention of this project proposal is not > > directly to integrate Shenandoah into upstream Hotspot yet (that's the > > purpose of the JEP, ultimately), but to provide a development space for > > Shenandoah under the OpenJDK umbrella, where it belongs, where OpenJDK > > people can easily try it out, etc. > > > > BTW, according to http://openjdk.java.net/projects/#new-project we need > > a Hotspot group lead to declare to sponsor the project: > > > > "At least one Group Lead must declare that their Group is a sponsor of > > the proposed Project." > > > > Best regards, > > Roman > > > > > >> Jon > >> > >>> Best regards, > >>> Roman > >>> > >>>> My impression of Shenandoah was that it would be a project > >>>> developed and maintained by Redhat and (I don't recall where > >>>> this last part of my recollection comes from) that it would be kept > >>>> separate from the OpenJDK hotspot sources. Is that all > >>>> correct? > >>>> > >>>> Jon > >>>> > >>>> On 2/19/2015 10:42 AM, Roman Kennke wrote: > >>>>> I'd like to discuss the creation of the project Shenandoah with myself > >>>>> *and/or* Christine Flood as initial lead and the Hotspot group as > >>>>> sponsoring group. > >>>>> > >>>>> It's aim is to implement a new garbage collector that reduces GC pause > >>>>> times for applications that require really large heaps. Existing GCs > >>>>> show pause times of several 100ms up to several seconds on heaps > > >>>>> 100GB. That is because they need to stop all Java threads for compacting > >>>>> the heap. Shenandoah implements a new algorithm that allows to compact > >>>>> heap while only stopping the Java threads briefly for root scanning, and > >>>>> then evacuates the heap concurrently. This makes pause times unrelated > >>>>> to the heap size and only proportional to the root set size. > >>>>> > >>>>> Shenandoah has so far been developed as part of the IcedTea project: > >>>>> > >>>>> http://icedtea.classpath.org/wiki/Shenandoah > >>>>> > >>>>> It has usable implementations for OpenJDK9 and OpenJDK8. > >>>>> > >>>>> Roman Kennke (me) is Principle Software Engineer at Red Hat, working on > >>>>> Shenandoah since two years now. Before this, he worked on Thermostat, > >>>>> and contributed to OpenJDK in several areas, most importantly the Zero > >>>>> and Shark ports, graphics, and ports to embedded platforms. > >>>>> > >>>>> Christine H. Flood is a prinicpal software engineer at Red Hat. Most > >>>>> recently she's been working on Shenandoah, before that she worked at > >>>>> Oracle/Sun labs on the Fortress programming language, and on JVM > >>>>> Scalability. She's one of the inventors of both the parallel GC > >>>>> algorithm and G1. > >>>>> > >>>>> Initial committers and reviewers would be me and Christine. > >>>>> > >>>>> Could we both be project leads? Christine doesn't have an OpenJDK > >>>>> idendity yet... > >>>>> > >>>>> Best regards, > >>>>> Roman > >>>>> > >>>>> > >> > > > > From roman at kennke.org Tue Mar 24 22:11:10 2015 From: roman at kennke.org (Roman Kennke) Date: Tue, 24 Mar 2015 23:11:10 +0100 Subject: Project proposal: Shenandoah In-Reply-To: <1427233506.2642.24.camel@kennke.org> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1427233506.2642.24.camel@kennke.org> Message-ID: <1427235070.2642.25.camel@kennke.org> Looks like the CC to John Coomes bounced. Is he still Hotspot group lead? Roman Am Dienstag, den 24.03.2015, 22:45 +0100 schrieb Roman Kennke: > Hi Jon and all, > > According to http://openjdk.java.net/projects/#new-project we need a > Hotspot group lead to declare to sponsor the project: > > "At least one Group Lead must declare that their Group is a sponsor of > the proposed Project." > > John Coomes (in CC) is the only Hotspot lead, as far as I can see. John, > do you think the Hotspot group could sponsor the Shenandoah project? > > I don't see any other group that would make sense as sponsor. I'd like > to put this up for voting as soon as I've got the ok from John Coomes. > > Thanks, > Roman > > Am Samstag, den 28.02.2015, 12:28 -0800 schrieb Jon Masamitsu: > > Roman, > > > > Thank you for the further information. This large a contribution > > is new territory for us so we'll be taking a bit of time to mull it > > over. > > > > Jon > > > > On 2/28/2015 5:01 AM, Roman Kennke wrote: > > > Hi Jon, > > > > > >>> Shenandoah is developed and maintained by Red Hat, yes, but the > > >>> intention is, and has always been, to integrate it into upstream > > >>> Hotspot, if OpenJDK people think it's feasible. The first step in this > > >>> direction is the creation of a Shenandoah project (this proposal) and we > > >>> also want to move forward with the Shenandoah JEP 189. > > >> I would also like to understand how an integration of Shenandoah into > > >> Hotspot would affect my day-to-day work. For example if I build Hotspot > > >> will I skip the build of Shenandoah sources by default? > > > Build-wise Shenandoah is a GC like all other GCs. When you build > > > Hotspot, you build Shenandoah. It will be excluded by setting > > > INCLUDE_ALL_GCS to false, iirc. We could add a build flag to exclude > > > Shenandoah, but I don't really see the point of it. > > > > > > Shenandoah is a bit special because it requires read and write barriers > > > in the interpreter, C1, C2 and the runtime. We tried as much as possible > > > to make this a clean interface, such to avoid scattering Shenandoah code > > > all over the place. One of our goals is to not impact performance or > > > behaviour with any other GC. If any other GC in the future requires > > > similar barriers, it could just implement those interfaces. It is not > > > perfect yet and needs some cleanup. > > > > > > All that being said, the intention of this project proposal is not > > > directly to integrate Shenandoah into upstream Hotspot yet (that's the > > > purpose of the JEP, ultimately), but to provide a development space for > > > Shenandoah under the OpenJDK umbrella, where it belongs, where OpenJDK > > > people can easily try it out, etc. > > > > > > BTW, according to http://openjdk.java.net/projects/#new-project we need > > > a Hotspot group lead to declare to sponsor the project: > > > > > > "At least one Group Lead must declare that their Group is a sponsor of > > > the proposed Project." > > > > > > Best regards, > > > Roman > > > > > > > > >> Jon > > >> > > >>> Best regards, > > >>> Roman > > >>> > > >>>> My impression of Shenandoah was that it would be a project > > >>>> developed and maintained by Redhat and (I don't recall where > > >>>> this last part of my recollection comes from) that it would be kept > > >>>> separate from the OpenJDK hotspot sources. Is that all > > >>>> correct? > > >>>> > > >>>> Jon > > >>>> > > >>>> On 2/19/2015 10:42 AM, Roman Kennke wrote: > > >>>>> I'd like to discuss the creation of the project Shenandoah with myself > > >>>>> *and/or* Christine Flood as initial lead and the Hotspot group as > > >>>>> sponsoring group. > > >>>>> > > >>>>> It's aim is to implement a new garbage collector that reduces GC pause > > >>>>> times for applications that require really large heaps. Existing GCs > > >>>>> show pause times of several 100ms up to several seconds on heaps > > > >>>>> 100GB. That is because they need to stop all Java threads for compacting > > >>>>> the heap. Shenandoah implements a new algorithm that allows to compact > > >>>>> heap while only stopping the Java threads briefly for root scanning, and > > >>>>> then evacuates the heap concurrently. This makes pause times unrelated > > >>>>> to the heap size and only proportional to the root set size. > > >>>>> > > >>>>> Shenandoah has so far been developed as part of the IcedTea project: > > >>>>> > > >>>>> http://icedtea.classpath.org/wiki/Shenandoah > > >>>>> > > >>>>> It has usable implementations for OpenJDK9 and OpenJDK8. > > >>>>> > > >>>>> Roman Kennke (me) is Principle Software Engineer at Red Hat, working on > > >>>>> Shenandoah since two years now. Before this, he worked on Thermostat, > > >>>>> and contributed to OpenJDK in several areas, most importantly the Zero > > >>>>> and Shark ports, graphics, and ports to embedded platforms. > > >>>>> > > >>>>> Christine H. Flood is a prinicpal software engineer at Red Hat. Most > > >>>>> recently she's been working on Shenandoah, before that she worked at > > >>>>> Oracle/Sun labs on the Fortress programming language, and on JVM > > >>>>> Scalability. She's one of the inventors of both the parallel GC > > >>>>> algorithm and G1. > > >>>>> > > >>>>> Initial committers and reviewers would be me and Christine. > > >>>>> > > >>>>> Could we both be project leads? Christine doesn't have an OpenJDK > > >>>>> idendity yet... > > >>>>> > > >>>>> Best regards, > > >>>>> Roman > > >>>>> > > >>>>> > > >> > > > > > > > > > > From volker.simonis at gmail.com Wed Mar 25 09:52:24 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 25 Mar 2015 10:52:24 +0100 Subject: Project proposal: Shenandoah In-Reply-To: <1427235070.2642.25.camel@kennke.org> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1427233506.2642.24.camel@kennke.org> <1427235070.2642.25.camel@kennke.org> Message-ID: According to LinkedIn, John Coomes is working for Twitter since January 2015. The OpenJDK roles aren't related to a specific employer in any way and while I would especially appreciate to have more OpenJDK roles filled with people from outside Oracle the current situation is a little bit unfortunate. That's mainly because we don't have OpenJDK mail accounts and the census page doesn't list the contact information of the OpenJDK members. So we should either introduce OpenJDK mail aliases which can be easily forwarded to new email addresses or make it possible to somehow contact people who are listed on the OpenJDK census page. This should be especially true for function owners like project leads. I also wish that Oracle would be a little more "open" here - at least they must have known that the HotSpot group lead has left their company and they had the possibility to pro-actively communicate this fact and its implications. Regards, Volker On Tue, Mar 24, 2015 at 11:11 PM, Roman Kennke wrote: > Looks like the CC to John Coomes bounced. Is he still Hotspot group > lead? > > Roman > > Am Dienstag, den 24.03.2015, 22:45 +0100 schrieb Roman Kennke: >> Hi Jon and all, >> >> According to http://openjdk.java.net/projects/#new-project we need a >> Hotspot group lead to declare to sponsor the project: >> >> "At least one Group Lead must declare that their Group is a sponsor of >> the proposed Project." >> >> John Coomes (in CC) is the only Hotspot lead, as far as I can see. John, >> do you think the Hotspot group could sponsor the Shenandoah project? >> >> I don't see any other group that would make sense as sponsor. I'd like >> to put this up for voting as soon as I've got the ok from John Coomes. >> >> Thanks, >> Roman >> >> Am Samstag, den 28.02.2015, 12:28 -0800 schrieb Jon Masamitsu: >> > Roman, >> > >> > Thank you for the further information. This large a contribution >> > is new territory for us so we'll be taking a bit of time to mull it >> > over. >> > >> > Jon >> > >> > On 2/28/2015 5:01 AM, Roman Kennke wrote: >> > > Hi Jon, >> > > >> > >>> Shenandoah is developed and maintained by Red Hat, yes, but the >> > >>> intention is, and has always been, to integrate it into upstream >> > >>> Hotspot, if OpenJDK people think it's feasible. The first step in this >> > >>> direction is the creation of a Shenandoah project (this proposal) and we >> > >>> also want to move forward with the Shenandoah JEP 189. >> > >> I would also like to understand how an integration of Shenandoah into >> > >> Hotspot would affect my day-to-day work. For example if I build Hotspot >> > >> will I skip the build of Shenandoah sources by default? >> > > Build-wise Shenandoah is a GC like all other GCs. When you build >> > > Hotspot, you build Shenandoah. It will be excluded by setting >> > > INCLUDE_ALL_GCS to false, iirc. We could add a build flag to exclude >> > > Shenandoah, but I don't really see the point of it. >> > > >> > > Shenandoah is a bit special because it requires read and write barriers >> > > in the interpreter, C1, C2 and the runtime. We tried as much as possible >> > > to make this a clean interface, such to avoid scattering Shenandoah code >> > > all over the place. One of our goals is to not impact performance or >> > > behaviour with any other GC. If any other GC in the future requires >> > > similar barriers, it could just implement those interfaces. It is not >> > > perfect yet and needs some cleanup. >> > > >> > > All that being said, the intention of this project proposal is not >> > > directly to integrate Shenandoah into upstream Hotspot yet (that's the >> > > purpose of the JEP, ultimately), but to provide a development space for >> > > Shenandoah under the OpenJDK umbrella, where it belongs, where OpenJDK >> > > people can easily try it out, etc. >> > > >> > > BTW, according to http://openjdk.java.net/projects/#new-project we need >> > > a Hotspot group lead to declare to sponsor the project: >> > > >> > > "At least one Group Lead must declare that their Group is a sponsor of >> > > the proposed Project." >> > > >> > > Best regards, >> > > Roman >> > > >> > > >> > >> Jon >> > >> >> > >>> Best regards, >> > >>> Roman >> > >>> >> > >>>> My impression of Shenandoah was that it would be a project >> > >>>> developed and maintained by Redhat and (I don't recall where >> > >>>> this last part of my recollection comes from) that it would be kept >> > >>>> separate from the OpenJDK hotspot sources. Is that all >> > >>>> correct? >> > >>>> >> > >>>> Jon >> > >>>> >> > >>>> On 2/19/2015 10:42 AM, Roman Kennke wrote: >> > >>>>> I'd like to discuss the creation of the project Shenandoah with myself >> > >>>>> *and/or* Christine Flood as initial lead and the Hotspot group as >> > >>>>> sponsoring group. >> > >>>>> >> > >>>>> It's aim is to implement a new garbage collector that reduces GC pause >> > >>>>> times for applications that require really large heaps. Existing GCs >> > >>>>> show pause times of several 100ms up to several seconds on heaps > >> > >>>>> 100GB. That is because they need to stop all Java threads for compacting >> > >>>>> the heap. Shenandoah implements a new algorithm that allows to compact >> > >>>>> heap while only stopping the Java threads briefly for root scanning, and >> > >>>>> then evacuates the heap concurrently. This makes pause times unrelated >> > >>>>> to the heap size and only proportional to the root set size. >> > >>>>> >> > >>>>> Shenandoah has so far been developed as part of the IcedTea project: >> > >>>>> >> > >>>>> http://icedtea.classpath.org/wiki/Shenandoah >> > >>>>> >> > >>>>> It has usable implementations for OpenJDK9 and OpenJDK8. >> > >>>>> >> > >>>>> Roman Kennke (me) is Principle Software Engineer at Red Hat, working on >> > >>>>> Shenandoah since two years now. Before this, he worked on Thermostat, >> > >>>>> and contributed to OpenJDK in several areas, most importantly the Zero >> > >>>>> and Shark ports, graphics, and ports to embedded platforms. >> > >>>>> >> > >>>>> Christine H. Flood is a prinicpal software engineer at Red Hat. Most >> > >>>>> recently she's been working on Shenandoah, before that she worked at >> > >>>>> Oracle/Sun labs on the Fortress programming language, and on JVM >> > >>>>> Scalability. She's one of the inventors of both the parallel GC >> > >>>>> algorithm and G1. >> > >>>>> >> > >>>>> Initial committers and reviewers would be me and Christine. >> > >>>>> >> > >>>>> Could we both be project leads? Christine doesn't have an OpenJDK >> > >>>>> idendity yet... >> > >>>>> >> > >>>>> Best regards, >> > >>>>> Roman >> > >>>>> >> > >>>>> >> > >> >> > > >> > >> > >> >> >> > > From dalibor.topic at oracle.com Wed Mar 25 11:55:18 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 25 Mar 2015 12:55:18 +0100 Subject: Project proposal: Shenandoah In-Reply-To: References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1427233506.2642.24.camel@kennke.org> <1427235070.2642.25.camel@kennke.org> Message-ID: <5512A226.6040802@oracle.com> On 25.03.2015 10:52, Volker Simonis wrote: > So we should either introduce OpenJDK mail aliases which can be easily > forwarded to new email addresses or make it possible to somehow > contact people who are listed on the OpenJDK census page. This should > be especially true for function owners like project leads. The Bylaws provide ways to handle transition of Group & Project Leads without requiring publication of (potentially) private (contact) information. The simplest mode of transition is for a person to resign from a leadership role, followed by nomination of another. Details depend on the role in question, of course. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From volker.simonis at gmail.com Wed Mar 25 13:49:45 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 25 Mar 2015 14:49:45 +0100 Subject: Project proposal: Shenandoah In-Reply-To: <5512A226.6040802@oracle.com> References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1427233506.2642.24.camel@kennke.org> <1427235070.2642.25.camel@kennke.org> <5512A226.6040802@oracle.com> Message-ID: On Wed, Mar 25, 2015 at 12:55 PM, dalibor topic wrote: > > > On 25.03.2015 10:52, Volker Simonis wrote: >> >> So we should either introduce OpenJDK mail aliases which can be easily >> forwarded to new email addresses or make it possible to somehow >> contact people who are listed on the OpenJDK census page. This should >> be especially true for function owners like project leads. > > > The Bylaws provide ways to handle transition of Group & Project Leads > without requiring publication of (potentially) private (contact) > information. > > The simplest mode of transition is for a person to resign from a leadership > role, followed by nomination of another. Details depend on the role in > question, of course. > All I can find in the Bylaws is the provision for the case where a Group or Project Lead resigns or departs. As to my knowledge non of these two cases happened, according to the Bylaws John is still the Hotspot Group Lead. And as I wrote before - I would really appreciate to have a HotSpot group lead who is not an Oracle employee. But we can not know what John's plans are, so the only possibility I can find in the Bylaws for this situation is to raise a motion to remove him as group lead. On the other hand that seems unnecessarily harsh to me. I think the only ones who can handle this a little more gracefully are the people from the HotSpot group within Oracle. So maybe somebody can speak up? I can not imagine you guys are really surprised by this situation :) Regards, Volker > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From neugens at redhat.com Wed Mar 25 15:05:33 2015 From: neugens at redhat.com (Mario Torre) Date: Wed, 25 Mar 2015 16:05:33 +0100 Subject: Project proposal: Shenandoah In-Reply-To: References: <1424371356.29919.20.camel@localhost> <54F0B27B.3010401@oracle.com> <1425063556.32230.92.camel@localhost> <54F0E172.3090404@oracle.com> <1425128485.32230.109.camel@localhost> <54F22501.8050304@oracle.com> <1427233506.2642.24.camel@kennke.org> <1427235070.2642.25.camel@kennke.org> <5512A226.6040802@oracle.com> Message-ID: <1427295933.3866.143.camel@galactica> On Wed, 2015-03-25 at 14:49 +0100, Volker Simonis wrote: > On Wed, Mar 25, 2015 at 12:55 PM, dalibor topic > wrote: > > > > > > On 25.03.2015 10:52, Volker Simonis wrote: > >> > >> So we should either introduce OpenJDK mail aliases which can be easily > >> forwarded to new email addresses or make it possible to somehow > >> contact people who are listed on the OpenJDK census page. This should > >> be especially true for function owners like project leads. > > > > > > The Bylaws provide ways to handle transition of Group & Project Leads > > without requiring publication of (potentially) private (contact) > > information. > > > > The simplest mode of transition is for a person to resign from a leadership > > role, followed by nomination of another. Details depend on the role in > > question, of course. > > > > All I can find in the Bylaws is the provision for the case where a > Group or Project Lead resigns or departs. As to my knowledge non of > these two cases happened, according to the Bylaws John is still the > Hotspot Group Lead. And as I wrote before - I would really appreciate > to have a HotSpot group lead who is not an Oracle employee. > > But we can not know what John's plans are, so the only possibility I > can find in the Bylaws for this situation is to raise a motion to > remove him as group lead. On the other hand that seems unnecessarily > harsh to me. Well according to census[1], John Coomes is still the HotSpot project lead, so giving the benefit of doubt I would wait a couple days before doing it (just in case he is in holiday or such). As you note too, I didn't see any email going around to announcing him to resign or a new lead to be proposed. I think bringing this up formally to the Bylaw would be pretty harsh indeed, I don't think that bringing the issue this situation is causing is though. > I think the only ones who can handle this a little more gracefully are > the people from the HotSpot group within Oracle. So maybe somebody can > speak up? I can not imagine you guys are really surprised by this > situation :) Cheers, Mario [1] http://openjdk.java.net/census#jcoomes From mikael.vidstedt at oracle.com Mon Mar 30 21:21:58 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 30 Mar 2015 14:21:58 -0700 Subject: Project proposal: Shenandoah In-Reply-To: <1424371356.29919.20.camel@localhost> References: <1424371356.29919.20.camel@localhost> Message-ID: <5519BE76.7010602@oracle.com> Roman, Having looked at your proposal in some detail, I have no reservations about it being an OpenJDK Project. We are working on resolving the HotSpot Group Lead question and should soon be able to have the HotSpot Group sponsor the Project, allowing you to proceed to the next step in Project creation. As Jon said, a potential contribution of a new GC would be entirely new territory for us, so I can't recommend a specific course of action with respect to your JEP and its potential future integration until you have had some time to pursue your Project under the OpenJDK umbrella, and others have had a chance to evaluate it. My overriding concern is about the maintainability of the HotSpot code base and the potential increased maintenance burden that could arise from integration of a new GC. That's the part I have serious reservations about, and while I understand that you're not looking to integrate your code into HotSpot just yet, I do want to register them to make sure that when the time comes they are given their due consideration. Cheers, Mikael On 2015-02-19 10:42, Roman Kennke wrote: > I'd like to discuss the creation of the project Shenandoah with myself > *and/or* Christine Flood as initial lead and the Hotspot group as > sponsoring group. > > It's aim is to implement a new garbage collector that reduces GC pause > times for applications that require really large heaps. Existing GCs > show pause times of several 100ms up to several seconds on heaps > > 100GB. That is because they need to stop all Java threads for compacting > the heap. Shenandoah implements a new algorithm that allows to compact > heap while only stopping the Java threads briefly for root scanning, and > then evacuates the heap concurrently. This makes pause times unrelated > to the heap size and only proportional to the root set size. > > Shenandoah has so far been developed as part of the IcedTea project: > > http://icedtea.classpath.org/wiki/Shenandoah > > It has usable implementations for OpenJDK9 and OpenJDK8. > > Roman Kennke (me) is Principle Software Engineer at Red Hat, working on > Shenandoah since two years now. Before this, he worked on Thermostat, > and contributed to OpenJDK in several areas, most importantly the Zero > and Shark ports, graphics, and ports to embedded platforms. > > Christine H. Flood is a prinicpal software engineer at Red Hat. Most > recently she's been working on Shenandoah, before that she worked at > Oracle/Sun labs on the Fortress programming language, and on JVM > Scalability. She's one of the inventors of both the parallel GC > algorithm and G1. > > Initial committers and reviewers would be me and Christine. > > Could we both be project leads? Christine doesn't have an OpenJDK > idendity yet... > > Best regards, > Roman > >