Dear Community, Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514) Congratulations on getting this working!, great job. I cannot conceal how disappointed I am, as is the whole team at Szeged. It was months ago, when we presented you our first results in the Bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986). Since then, we exchanged ideas in several comments and even received feedbacks and suggestions from you. Now, I pose the question (possibly only to myself): "For what end?" I'm quite sure that the work on your side has been ongoing for some time now. Still, you did not mention anything. We did not even get a notification on the new port. Of course, we've felt that you were reluctant to accept our implementation. At least, now we know why. As WebKit currently is, it is not an open community. Not at all. Let me ask two final questions: - Are you still looking for patches, bug reports, feature requests, etc., or is it all in vain - you will get everything done inhouse? - Should we ask for credits in the new files, as it was done by you when we first published our JIT implementation? I'm quite sure that we can state the same argument: "a number of the new files appear to have taken large chunks of logic from existing jit files". Best regards, Akos
Hi Akos.
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514 ) Congratulations on getting this working!, great job.
Thanks.
I cannot conceal how disappointed I am, as is the whole team at Szeged.
I'm sorry to hear that. I understand your disappointment, but I have to admit that I'm excited to have a close-to-enabled, fast ARM JIT in the WebKit repository, that builds on JavaScriptCore's existing infrastructure and design.
It was months ago, when we presented you our first results in the Bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986). Since then, we exchanged ideas in several comments and even received feedbacks and suggestions from you. Now, I pose the question (possibly only to myself): "For what end?" I'm quite sure that the work on your side has been ongoing for some time now. Still, you did not mention anything. We did not even get a notification on the new port.
Of course, we've felt that you were reluctant to accept our implementation. At least, now we know why.
As WebKit currently is, it is not an open community. Not at all.
I don't think that's fair. Looking at https://bugs.webkit.org/show_bug.cgi?id=24986, I see three detailed comments by Oliver Hunt, and two by Gavin Barraclough, explaining our thinking about how an ARM JIT should be organized to best effect. I think you'll find those comments strongly reflected in http://trac.webkit.org/changeset/44514 .
Let me ask two final questions: - Are you still looking for patches, bug reports, feature requests, etc.,
Yes.
- Should we ask for credits in the new files, as it was done by you when we first published our JIT implementation? I'm quite sure that we can state the same argument: "a number of the new files appear to have taken large chunks of logic from existing jit files".
Generally, a new file that copies substantial code from an old file should include the old file's copyrights, along with the new author's copyright. Usually, this happens naturally via svn cp, but sometimes people forget or use other processes. If you notice a patch that is remiss in this area, please do mention something, with specifics. Cheers, Geoff
On Tuesday 09 June 2009 23:38:43 Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514) Congratulations on getting this working!, great job.
I cannot conceal how disappointed I am, as is the whole team at Szeged.
I can understand how bad you feel and I agree that "Apple does not comment on future products."-mantra can suck at times. When you look at the ARM JIT of Apple you will see they mostly target Cortex-A8 (thumb2, vfp) and IIRC your JIT is much wider (supporting many more existing devices). So my bottom line is something like please don't give up, and contributing to the JIT should be more easy now. E.g. pick a topic/theme for your work and try to get it in. I can not share that WebKit is not a open community. Of course there are vendor interests and Apple, Nokia and Torchmobile don't share some of them. E.g. Apple probably does not see the value of XHTML MP, ECMA MP and WML and still these changes go on... z.
Hi there, I would also say that is it pretty understanding that Apple does not share information about working on a ARM JIT targeting thumb2, especially as this can be used to foresee the hardware of future iPhone models. Something they are probably not interesting in revealing. I agree whole-hearted with Holger, that the chances for getting ARM JIT enhancements upsteamed now have been greatly improved; and with Apple working on the same code I would expect good reviews and lots of care for the ARM code base. We really rely on you guys for bringing the ARM JIT code to other versions of ARM, and I would like to say that I consider your contributions important and very welcome, and would like to encourage your to keep contributing! Please keep up the good work! Kenneth On Tue, Jun 9, 2009 at 9:20 PM, Holger Freyther<zecke@selfish.org> wrote:
On Tuesday 09 June 2009 23:38:43 Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514) Congratulations on getting this working!, great job.
I cannot conceal how disappointed I am, as is the whole team at Szeged.
I can understand how bad you feel and I agree that "Apple does not comment on future products."-mantra can suck at times. When you look at the ARM JIT of Apple you will see they mostly target Cortex-A8 (thumb2, vfp) and IIRC your JIT is much wider (supporting many more existing devices).
So my bottom line is something like please don't give up, and contributing to the JIT should be more easy now. E.g. pick a topic/theme for your work and try to get it in.
I can not share that WebKit is not a open community. Of course there are vendor interests and Apple, Nokia and Torchmobile don't share some of them. E.g. Apple probably does not see the value of XHTML MP, ECMA MP and WML and still these changes go on...
z. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514 ) Congratulations on getting this working!, great job.
Hi Akos, Thank you! Just to clarify, we have just landed a ARMv7 architecture (thumb2) JIT backend into ToT. I say ARMv7 to distinguish this port from the ARM application instruction set found in the ARMv6 architecture and earlier (as I believe would be a common understanding of the term ARM, and and which I believe your port targets). Thumb2 in ARMv7 is, of course, a very different instruction set to the traditional 32-bit instructions found in ARM – with completely different machine encodings, and significantly different capabilities (e.g. two operand versus three operand instructions, sizes of immediate operands, and options for instruction predication). For the JIT to be able to run on both ARM and ARMv7 platforms, it needs to be ported to both architectures – in much the same way the the JIT is ported to both the x86 and x86-64 platforms. Obviously there is a great deal of similarity on the surface between ARM and ARMv7, but in terms of the JIT implementation that may well only be true above the level of the MacroAssembler interface. There may be some limited opportunities to share code within the Assembler classes (register numbering enums, and possibly types describing immediate operands), but since the assembler is primarily concerned with formatting machine instructions, and since the instruction encodings are different, it seems likely the bulk of the code will have to remain separate. Again, the differences in instruction selection options available on the two architectures will likely make it hard to share code within the MacroAssember (different numbers of operands to many common instructions, and the options when working with large immediate values particularly spring to mind). We would certainly want to share code and avoid any duplication where ever it makes sense to do so.
I cannot conceal how disappointed I am, as is the whole team at Szeged.
I am very sorry to hear this. If you look at the patches that landed into ToT there were very few changes made outside of the new assembler classes which, for the reasons described above, I think are highly unlikely to have much in common on the two platforms. The changes that have been made to common code outside of the assemblers should only help in removing x86 dependencies and assumptions that had existed in the code. I strongly urge you to review the changes that have been made, as I hope and believe you will find that they will assist the team in integrating your ARM port.
Of course, we've felt that you were reluctant to accept our implementation.
We were (and remain) reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. We are concerned that it would be extremely difficult to continue to maintain such a port as we move the JIT technology forwards. Beyond that, they key barrier to the ARM JIT being accepted into WebKit is that there simply haven't been any patches put forwards for us to review! (I'm sorry, I'm aware you have provided a link to an external git repository, but I'm afraid we really can't seek through version control systems to find changes to review – we do need contributors to attach patches to bugs, and we need a review flag setting to indicate when the contributor believes their patch is ready. If there is any uncertainty as to the procedure, please see http://webkit.org/coding/contributing.html .)
- Are you still looking for patches, bug reports, feature requests, etc., or is it all in vain - you will get everything done in house?
Yes! Please do so, this is only way your changes will get into the tree.
- Should we ask for credits in the new files, as it was done by you when we first published our JIT implementation? I'm quite sure that we can state the same argument: "a number of the new files appear to have taken large chunks of logic from existing jit files".
The new files were derived from their x86 counterparts, with reference to the ARMv7 manuals. As such the existing copyright notifications within the files from which they were derived have been retained. (Apologies for the slow reply, we have a busy week with WWDC on!) cheers, G.
Best regards, Akos
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi guys at Apple, it looks we are in the way of the train. You have plans, we don't know about them, you have commit rights, we don't, so the tides are against us. Hints on the mailing lists are scarce, although a year ago someone from you asked whether others are interested in design discussions, we said 'yes', nothing really changed. Except some simple bugfixes, new patches of ours do not really get into the mainline (except some of our best ideas reimplemented by someone else). Partially this is due to the lack of information and roadmap of JavaScriptCore. That is why I feel the missing of the real openness. And here, I have to make a short comment on the non-acceptance of our ARM JIT implementation. In your mail you mention that you would remain reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. Well, did you check our ARM port? It has been rewritten to conform to the MacroAssembler interfaces more than a month ago and posted it into the bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986). Anyway, we have updated the MacroAssembler-based ARM port of ours, uploaded it to the bugzilla, and set the review flag on the patch. Regards, Zoltan
On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514 ) Congratulations on getting this working!, great job.
Hi Akos,
Thank you! Just to clarify, we have just landed a ARMv7 architecture (thumb2) JIT backend into ToT. I say ARMv7 to distinguish this port from the ARM application instruction set found in the ARMv6 architecture and earlier (as I believe would be a common understanding of the term ARM, and and which I believe your port targets). Thumb2 in ARMv7 is, of course, a very different instruction set to the traditional 32-bit instructions found in ARM – with completely different machine encodings, and significantly different capabilities (e.g. two operand versus three operand instructions, sizes of immediate operands, and options for instruction predication). For the JIT to be able to run on both ARM and ARMv7 platforms, it needs to be ported to both architectures – in much the same way the the JIT is ported to both the x86 and x86-64 platforms.
Obviously there is a great deal of similarity on the surface between ARM and ARMv7, but in terms of the JIT implementation that may well only be true above the level of the MacroAssembler interface. There may be some limited opportunities to share code within the Assembler classes (register numbering enums, and possibly types describing immediate operands), but since the assembler is primarily concerned with formatting machine instructions, and since the instruction encodings are different, it seems likely the bulk of the code will have to remain separate. Again, the differences in instruction selection options available on the two architectures will likely make it hard to share code within the MacroAssember (different numbers of operands to many common instructions, and the options when working with large immediate values particularly spring to mind). We would certainly want to share code and avoid any duplication where ever it makes sense to do so.
I cannot conceal how disappointed I am, as is the whole team at Szeged.
I am very sorry to hear this. If you look at the patches that landed into ToT there were very few changes made outside of the new assembler classes which, for the reasons described above, I think are highly unlikely to have much in common on the two platforms. The changes that have been made to common code outside of the assemblers should only help in removing x86 dependencies and assumptions that had existed in the code. I strongly urge you to review the changes that have been made, as I hope and believe you will find that they will assist the team in integrating your ARM port.
Of course, we've felt that you were reluctant to accept our implementation.
We were (and remain) reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. We are concerned that it would be extremely difficult to continue to maintain such a port as we move the JIT technology forwards. Beyond that, they key barrier to the ARM JIT being accepted into WebKit is that there simply haven't been any patches put forwards for us to review! (I'm sorry, I'm aware you have provided a link to an external git repository, but I'm afraid we really can't seek through version control systems to find changes to review – we do need contributors to attach patches to bugs, and we need a review flag setting to indicate when the contributor believes their patch is ready. If there is any uncertainty as to the procedure, please see http://webkit.org/coding/contributing.html .)
- Are you still looking for patches, bug reports, feature requests, etc., or is it all in vain - you will get everything done in house?
Yes! Please do so, this is only way your changes will get into the tree.
- Should we ask for credits in the new files, as it was done by you when we first published our JIT implementation? I'm quite sure that we can state the same argument: "a number of the new files appear to have taken large chunks of logic from existing jit files".
The new files were derived from their x86 counterparts, with reference to the ARMv7 manuals. As such the existing copyright notifications within the files from which they were derived have been retained.
(Apologies for the slow reply, we have a busy week with WWDC on!)
cheers, G.
Best regards, Akos
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
it looks we are in the way of the train. You have plans, we don't know about them, you have commit rights, we don't, so the tides are against us.
If you're interested in review or commit rights, they're granted based on a track record of good work, good judgement, and good collaboration. You can read more about the policy here: http://webkit.org/coding/commit-review-policy.html . Please work on your collaboration skills. Right now, your tone stinks. Geoff
If you're interested in review or commit rights, they're granted based on a track record of good work, good judgement, and good collaboration. You can read more about the policy here: http://webkit.org/coding/commit-review-policy.html .
Please work on your collaboration skills. Right now, your tone stinks.
I am sorry if I was not clear. I was talking about cooperation and openness, not about commit rights. Actually, I think it is unimportant who commit a patch, the important thing is that everyone should know what is happening. That is why I wrote those boring blog posts about technical details. Zoltan
And here, I have to make a short comment on the non-acceptance of our ARM JIT implementation. In your mail you mention that you would remain reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. Well, did you check our ARM port? It has been rewritten to conform to the MacroAssembler interfaces more than a month ago and posted it into the bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986).
Hi Zoltan, I'm sorry if I'm misinterpreting you here, but it sounds like over the last month you have been expecting your MacroAssembler based ARM port to have been reviewed. If so - Then I can quite understand your frustration, and do sympathize greatly with you. There clearly has been a breakdown in communication, and I'm sorry about your disappointment. I'm afraid that we had no way of knowing that you considered your port to be complete. Just last week, in an email on this list, I said, "when you have a patch ready for review, please attach it to the bug and set the review flag" – I was under the impression that you did not feel your changes were yet final (by the sound of it I was mistaken). I was assuming that when a final patch was ready you would attach it to the bug, and mark it for review. We have a procedure for accepting contributions to avoid exactly this kind of miscommunication. The mechanism for communicating to us that you believe your patch is ready is very simple, and is absolutely critical if you want to get code into WebKit. Patches ready for review must be marked as such in bugzilla. Without this we cannot tell which patches attached to bugs are complete, and which represent work in progress. I urge you to review the instructions on contributing on the website, since following these will be the only way to avoid similar disappointment in the future. Perhaps this is an area where we need to improve our communication – perhaps we need to make these instructions clearer, or more prominent on the website. The website is all stored in svn, so please do file bugs in bugzilla – or patches welcome – if you think these can be improved.
Anyway, we have updated the MacroAssembler-based ARM port of ours, uploaded it to the bugzilla, and set the review flag on the patch.
I've had a brief chance to look at the patch, and it's looking really great. There are some bits to clean up a little to get it through review, and we will want to land a change of this magnitude incrementally. I'm afraid that I have a busy day today, I will try to comment on the bug tonight but it may have to wait until the morning. Hopefully we can get this landed into ToT fairly quickly. cheers, G.
participants (6)
-
Akos Kiss
-
Gavin Barraclough
-
Geoffrey Garen
-
Holger Freyther
-
Kenneth Christiansen
-
Zoltan Herczeg