RFR: JDK-8067479: verify-modules fails in bootcycle build
staffan.larsen at oracle.com
Mon Jan 19 09:05:26 UTC 2015
SA changes look ok - the IA64 stuff isn’t needed as we don’t support it and will remove it.
> On 19 jan 2015, at 09:29, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Any chance someone from serviceability could take a look at this?
> On 2015-01-12 03:45, David Holmes wrote:
>> Hi Erik,
>> On 10/01/2015 12:34 AM, Erik Joelsson wrote:
>>> Please review this patch which fixes the verify-modules target when
>>> running bootcycle build, and also reenables verify-modules when running
>>> "make images".
>>> There were two problems:
>>> * The bootcycle build configuration was broken so that both the normal
>>> and the bootcycle build used the same HOTSPOT_DIST directory. The
>>> consequence of this was that verify-modules worked when run on its own,
>>> but not if bootcycle-images had been run before. This is fixed in
>>> * Since javac in JDK 9 no longer emits classes for implicitly compiled
>>> sources, certain classes in sa-jdi.jar were not compiled during the
>>> bootcycle build. I fixed this by adding the missing classes to sa.files.
>>> Not having the classes there might have been intentional (in at least
>>> some cases), but since they were compiled anyway, I felt it safer to
>>> just add them to the list to fix this issue. If these classes shouldn't
>>> be included, then they need to be properly removed in a followup fix.
>> SA is owned by serviceability - cc'd. Changes seem okay as a solution to immediate problem, but I don't think anyone expects the IA64 stuff to still be needed. It is on the todo list to eradicate IA64 IIRC.
>> Looks like there is limited awareness of the need to keep sa.files up to date. :(
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
>>> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/
>>> Since this is changing hotspot, I assume it will need to go in through a
>>> hotspot forest. Which one?
More information about the build-dev