RFR (S) 8227370 Remove SharedPathsMiscInfo

Jiangli Zhou jianglizhou at google.com
Fri Aug 23 15:47:58 UTC 2019


Hi,

It's not a complete code review yet. One good point that Calvin brought up
during the code review email discussion for the previous related change was
that runtime needs to check the non-existing JAR entries specified via the
Class-Path header in manifest. Could you please verify those cases are
handled properly with the change? Thanks.

Regards,
Jiangli

On Thu, Aug 22, 2019 at 8:28 AM Ioi Lam <ioi.lam at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8227370
>
> http://cr.openjdk.java.net/~iklam/jdk14/8227370_remove_shared_misc_info.v01/
>
> For the 3 types of items stored in SharedPathsMiscInfo
>
> BOOT_PATH/APP_PATH:
>
> These are used only for tracing. I reimplemented the tracing
> functionality in FileMapInfo::log_paths()
>
> NON_EXIST:
>
> It turns out we don't need to keep track of non-existent paths from the
> dump-time path.  We can simply eliminate all the non-existent paths from
> both the dump-time and runtime paths, and check that the remaining files
> match. E.g.,
>
> dump: -cp a.jar:NE1:NE2:b.jar
> run 1: -cp NE3:a.jar:NE4:b.jar
> run 2: -cp x.jar:NE4:b.jar
>
> after elimination:
>
> dump = a.jar:b.jar
> run 1 = a.jar:b.jar -> matched
> run 2 = x.jar:b.jar -> mismatched
>
> The dump-time elimination was already done in
> ClassLoader::update_class_path_entry_list().
> The run-time elimination was already done in
> FileMapInfo::create_path_array().
>
> So essentially I just tied things together and wrote a few more test cases
> in NonExistClasspath.java
>
>
> Testing: hs-tier{1,2,3}
>
>


More information about the hotspot-runtime-dev mailing list