RR(S): 8022655: ClassDump ignored jarStream setting
kevin.walls at oracle.com
Fri Aug 9 07:54:30 PDT 2013
Review request for a small change in ClassDump:
This was caused by moving some code from ClassDump's main method,
breaking the intent that it has to maintain either an output director,
OR a jarStream. Setting of the directory could be done unconditionally
when it was in main(), but not when in the run() method.
The tests test/compiler/ciReplay for compiler replay work (if you update
sa.js with a suggested fix from 8011888).
Trying those tests now on Solaris, I found coreadm settings may mean
they don't find the core: putting a coreadm command in the test means
we should find JTwork/scratch/core
On 08/08/2013 19:25, Yumin Qi wrote:
> I assigned this to you since it is caused by 8011888 fix.
> On 7/26/2013 2:20 AM, Kevin Walls wrote:
>> Hi Yumin,
>> Sure no problem I'll look into it. Looks like in ClassDump we
>> should check classFilter != null before doing that initialisation in
>> the run() method.
>> At the moment trying jtreg on test/compiler/ciReplay I get a failure
>> in TestSA.sh, as it calls sun.jvm.hotspot.CLHSDB, and gives the
>> suggested new sa.js I see in that bug, I'll test and let you know...
>> On 26/07/13 02:17, Yumin Qi wrote:
>>> Hi, Kevin
>>> I found this fix breaks C2 replay for dumping loaded java classes:
>>> The problem is with Replay, we set BootFilter and NonBootFilter
>>> for ClassDump, but this changeset ignored the existing filter.
>>> I filed a bug against this problem.
More information about the hotspot-compiler-dev