Hi Jim, >> 1. Do you prefer I send you another webrev including my last changes ? > > > Let me look through the latest webrev first.
Ok. FYI new changes are very small. I started writing the CrashTest class testing several corner cases with huge images & paths to force growable arrays to resize all but also testing the 2gb overflow on the offheap edge array. Of course some integer overflow checks are still missing but now Marlin passes that test although ductus fails. >> 2. I will be busy in november so I would like to anticipate Marlin > > > That's unfortunate as now that JavaOne is over I have more time to spend on this. I will attend a 1 week workshop in mid november so I must prepare both a talk and finish some work. However I will have some spare time left to work on the patch 4 but less than usual so I will not start new developments. >> What is the plan according to you ? > > > We can integrate at any point now I think. The main advantage of holding off is that there is less bureaucracy to get changes in, but when we have to coordinate via email I don't think the added burden of having to submit bugs for everything that we fix matters much anyway so that's a moot point for this effort. Agreed but there is few time left. Will you push J2dBench change soon ? > > The only change if I integrate is that we'll have to submit a bug report for everything that we change and we may end up doing the work in the main client jdk workspace. Also we'd have to focus on fixing one bug/thing per integration - no more "I did these 3 things" checkins. Phil can clarify further on this point. > > >> Could you merge gr forrest with latest jdk9 forrest ? > > > I'll take care of that shortly. Great ! I will then fix Marlin to use the new jdk.internal.Unsafe and maybe we could use the new Objects.rangecheck () methods ? > >> Do you need me to perform some cleanup (system properties, code >> formatting like modifiers ...) before pushing marlin into jdk9 ? > > > I can deal with most of that if you are out of time in the short term. That would be great. Please could you also enable Marlin as the default rasterizer ? So SQE tests will use it with its default settings. Maybe we could discard or remove few marlin settings. > >> Should we refactor the array cache asap ? or it can be done after the >> first integration. > > > That can be done later. We'd just have to file a bug saying that it needs work and then fix that bug... I may find some time to try implementing the cache reference wrappers I mentioned few times. Cheers, Laurent
