<div dir="ltr">Hi Volker,<div><br></div><div>I am going to post the code some time this week.</div><div>Stay tuned.</div><div><br></div><div>--Jungwoo</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 3:04 AM, Volker Simonis <span dir="ltr"><<a href="mailto:volker.simonis@gmail.com" target="_blank">volker.simonis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John, Jeremy,<br>
<br>
@John: sorry, but I don't see what's the big problem behind "supported<br>
and maintained by the community". We already have quite some code in<br>
the HotSpot which is developed and maintained that way. Take for<br>
example the C++-Interpreter. It has not been used and supported by<br>
Sun/Oracle since 1.4 where it was used for the Itanium port.<br>
Nevertheless it is quite useful for HotSpot ports to new platforms. We<br>
at SAP used it for our intitial PowerPC port for example. And of<br>
course we supported it. This includes both fixes as well as the<br>
implementation of new features (e.g. supports for JSR 292). Another<br>
user of the C++-interpreter is the Zero-port which is supported mainly<br>
by RedHat. Again, Oracle does neither build nor test the Zero-port.<br>
This is all done by RedHat. But it is still a crucial part of the<br>
OpenJDK for platforms like Linux on zArch, MIPS, Itanium,....<br>
<br>
Then we (i.e. SAP and IBM) have our ports (Linux/PPC64, AIX) and<br>
RedHat have their AArch64 port. Neither of them is supported by Oracle<br>
but all of them are pretty well supported by their maintainers. We<br>
have our own platform categories in the bug system, our OpenJDK<br>
mailing lists. We do nightly builds and tests and we take all this<br>
pretty seriously. And that all imposes nearly zero overhead on Oracle<br>
but rather helps to strengthen the VM on all platforms (e.g. we<br>
contributed quite some GC-fixes which only showed up on a weak memory<br>
architecture like Power or helped to clean up the code because we use<br>
different compiler on other platforms).<br>
<br>
I don't think it is appropriate for an Open Source project to reject a<br>
new feature just because one of the maintainers doesn't want it. And<br>
the OpenJDK is an OpenSource project with a distinct development model<br>
as specified in the OpenJDK bylaws (<a href="http://openjdk.java.net/bylaws" target="_blank">http://openjdk.java.net/bylaws</a>).<br>
But I don't want to go on collision course. Until now the cooperation<br>
between the various contributors in the OpenJDK has always worked<br>
quite well. And if a feature can really be hidden behind a flag<br>
without impacting the other configurations that's great. Of course<br>
Oracle would not have to maintain or even test it (there already exist<br>
a myriad of unsupported configurations today :). And I think it is<br>
self-evident that contributors feel responsible for bugs in their code<br>
and fix them (as we already do today). So the only commitment on<br>
Oracle part would be to help with the initial review process which I'd<br>
consider acceptable.<br>
<br>
@Jeremy: could you please post some code so we can see what we're<br>
really talking about here. It seems that until now nobody ever saw<br>
these changes. And maybe it helps if several parties are trying<br>
jointly to 'convince' the maintainer to consider a patch :)<br>
<br>
Regards,<br>
Volker<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Jun 5, 2015 at 5:56 PM, Jon Masamitsu <<a href="mailto:jon.masamitsu@oracle.com">jon.masamitsu@oracle.com</a>> wrote:<br>
><br>
><br>
> On 6/3/2015 1:00 PM, Jeremy Manson wrote:<br>
><br>
> I'm not on hotspot-gc-dev, so I'm not seeing the responses. But I looked<br>
> online...<br>
><br>
> Jon says that "My understanding was that the change was based on a<br>
> parallelization of the serial mark-sweep-compact (used by CMS for full<br>
> collections). If it was based on the parallel-old compaction used by<br>
> ParallelGC, then my bad. It should have been reviewed."<br>
><br>
> His original understanding was correct - we parallelized the serial<br>
> mark-sweep-compact used by CMS. I'm sorry if I misled anyone there.<br>
><br>
><br>
> No problem. It gave me a chance to say again that<br>
> I'd rather not have to support two implementations of<br>
> a parallel full stop-the-world collector. We have that<br>
> issue with the two implementations of a parallel young<br>
> collector and I'd really rather not go there again.<br>
><br>
><br>
> Otherwise, thanks for your thoughtful reply, Volker. In my experience of<br>
> open source projects, if you can't get a maintainer to agree to consider<br>
> your patch, then there is really very little that you can do. And I totally<br>
> get that maintainers don't want / have the time for the burden of<br>
> understanding huge amounts of complicated code they didn't write!<br>
><br>
> So, the question comes down to what "community supported" means in this<br>
> case. We can't actually submit anything to Hotspot without approval from<br>
> someone within Oracle. We have a vested interest in keeping this patch<br>
> working, but, for major JDK releases, we really only start stress testing to<br>
> identify problems with it when we upgrade to the latest versions of the JDK,<br>
> which usually happens some months after Oracle releases it. That could<br>
> cause some issues for upstream.<br>
><br>
> The upside is that I think we'd be willing to do what it takes, if getting<br>
> it upstreamed is a possibility. This patch is a huge nuisance, and it is<br>
> much simpler not to have to do a week or two's worth of forward porting<br>
> every year. And whatever problems arise are problems that we have to fix<br>
> anyway.<br>
><br>
> Jon, if you are particularly worried, note that we can keep it hidden behind<br>
> a flag without too much difficulty (and did for a year or two).<br>
><br>
><br>
> I don't think that helps much. Unless Google is willing to own any<br>
> bug reports that come in on CMS when it is turned on. My main<br>
> concern is long term support. And whether we would have to<br>
> do our testing with it both turned on and turned off. Both those<br>
> seem like a big commitment on Oracle's part. Only my opinion,<br>
> of course.<br>
><br>
> Jon<br>
><br>
><br>
> Jeremy<br>
><br>
> On Wed, Jun 3, 2015 at 2:32 AM, Volker Simonis <<a href="mailto:volker.simonis@gmail.com">volker.simonis@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Jeremy,<br>
>><br>
>> thanks for your answer. Maybe you misunderstood Ivan but it is definitely<br>
>> his and our (i.e. SAP's) intention to make this part of the OpenJDK.<br>
>><br>
>> I can also fully understand the pains you have with integrating changes<br>
>> into the HotSpot. We've gone through this painful process with our ppc64<br>
>> port a year ago but we think it will finally pay off. After all you (i.e.<br>
>> Google) used it as the base for your ppc64le port (Alexander Smundak<br>
>> contributed most of the LE-specific changes).<br>
>><br>
>> We're facing the exactly same problems regarding the support of<br>
>> proprietary changes in a downstream version of the OpenJDK. That was<br>
>> actually the main reason why we started contributing to the OpenJDK. What we<br>
>> want to kindly ask you is to make your changes and extensions more<br>
>> transparently visible to the community if you intend to integrate them into<br>
>> the OpenJDK. If Hiroshi had posted his changes directly to the hotspot<br>
>> mailing lists instead of sending them privately to Jon I'm pretty sure we<br>
>> would have picked them up. And maybe together we would have managed to push<br>
>> them through (we have some reviewers as well :). After all, there are<br>
>> already quite a lot of features in the OpenJDK which are supported and<br>
>> maintained by the community (i.e. RedHat, IBM, SAP, ...) and not by Oracle.<br>
>><br>
>> I don't have much experience with other Open Source projects, but with<br>
>> OpenJDK and especially HotSpot it's pretty pointless to try to contribute<br>
>> something by writing mails like "..I've implemented this cool feature XXX.<br>
>> If somebody is interested I can post more details..". You'll almost never<br>
>> get any feedback to such kind of requests. You'll at least have to post a<br>
>> complete buildabel and runnable patch against the head revision. I know<br>
>> that's a lot of overhead and we're having this very same discussion if it is<br>
>> worth doing it nearly every day for most of the features/additions we are<br>
>> implementing. Nevertheless, I think it is worth doing it although it<br>
>> sometimes may take years until you get your changes back in the version you<br>
>> are using productively.<br>
>><br>
>> So coming back to Ivan's initial request, we would kindly ask you to just<br>
>> publish your changes in their current form against your current version<br>
>> (8u45 or whatsoever). We'll take a look at them an may invest some time and<br>
>> effort (also jointly with you if desired) to forward port them to 9 and<br>
>> propose them for integration into the head revision if that makes sense.<br>
>> Thus that sound reasonable to you?<br>
>><br>
>> Thank you and best regards,<br>
>> Volker<br>
>><br>
>><br>
>> On Tue, Jun 2, 2015 at 5:00 PM, Jeremy Manson <<a href="mailto:jeremymanson@google.com">jeremymanson@google.com</a>><br>
>> wrote:<br>
>>><br>
>>> We'd much rather it be part of OpenJDK, because it is large and fairly<br>
>>> complicated, so that would save us time and energy forward porting it every<br>
>>> year or so. It's pretty large (for 8u45, it is a 2600 line change and<br>
>>> touches 20 files), so it tends to be a lengthy and complicated forward port.<br>
>>> We would much rather spend that time doing something more interesting.<br>
>>><br>
>>> Just posting an updated patch whenever we need to update it would be a<br>
>>> little annoying (although not impossible).<br>
>>><br>
>>> Hiroshi Yamauchi tried to offer it to (I think it was) Jon Masamitsu a<br>
>>> few years ago, and Jon didn't know anyone with the bandwidth to review it.<br>
>>> (It was around the same time we contributed the parallel initial mark). I<br>
>>> believe that was when CMS was unowned for a while. Perhaps there's a<br>
>>> different story now? Oracle volunteers?<br>
>>><br>
>>> (Procedural: One problem is that Hotspot reviews have to go through<br>
>>> someone at Oracle. We had it written by an OpenJDK author and reviewed by a<br>
>>> reviewer. We've been using it in production for years without too many<br>
>>> headaches (although we have yet to inflict^Wlaunch 8u45, which has the<br>
>>> latest updates, widely). I totally understand that Oracle folks are the<br>
>>> ones who have to pay the price for a bad check-in, but it's a pretty big<br>
>>> hurdle for us.)<br>
>>><br>
>>> Jeremy<br>
>>><br>
>>> On Tue, Jun 2, 2015 at 6:12 AM, Galkin, Ivan <<a href="mailto:ivan.galkin@sap.com">ivan.galkin@sap.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>><br>
>>>><br>
>>>> in the thread „JEP 248: Make G1 the Default Garbage Collector” [1] there<br>
>>>> is an email from Jeremy Manson, who mentions the enhancements made by Google<br>
>>>> to improve CMS.<br>
>>>><br>
>>>> Especially the parallelizing of full compaction is a great improvement<br>
>>>> and we at SAP see the strong demand of it.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> @Jeremy: Are these changes published somewhere? May we have insight into<br>
>>>> the diffs you've made? We could collaborate in order to try to bring your<br>
>>>> changes into OpenJDK.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Kind regards and thank you in advance,<br>
>>>><br>
>>>> Ivan<br>
>>>><br>
>>>><br>
>>>><br>
>>>> [1]<br>
>>>> <a href="http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018740.html" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018740.html</a><br>
>>><br>
>>><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:12.8000001907349px">Jungwoo Ha | Java Platform Team | <a href="mailto:jwha@google.com" target="_blank">jwha@google.com</a></span><br></div><div><br></div></div></div>
</div></div></div>