JEP proposed to target JDK 13: 350: Dynamic CDS Archives

Ioi Lam ioi.lam at oracle.com
Wed May 1 16:53:23 UTC 2019


The dynamic archive can also be shared across processes running on the 
same host, as long as they are running the same program.

So if you're running multiple copies of the same program, then using the 
old method (single static archive) is roughly the same as the new method 
(static archive + dynamic archive).

If your environment runs different programs that share the same set of 
libraries. e.g.,

     2 processes running with "-cp:lib.jar:foo.jar FooApp"
     4 processes running with "-cp:lib.jar:bar.jar BarApp"

to achieve best sharing, you can create a static archive (using a 
classlist) for only the classes in lib.jar (and any other system classes 
used by these apps). Then, create two different dynamic archives, one 
for the "foo" app, and the other for the "bar" app.

This way, the static archive can be shared across all 6 processes, and 
the dynamic archives can be shared among the processes running the same 
program.

Thanks
- Ioi


On 5/1/19 8:27 AM, Michael Bien wrote:
> since each JVM process would create its own dynamic class data 
> archive, on top of a static archive, i would assume that only the 
> static archive would be shared between processes, while the dynamic 
> archive would be mostly only beneficial for tuning startup time.
>
> Manually created static AppCDS archives on the other hand are fully 
> shareable and can help with both, footprint and startup time.
>
> Would this be correct or is more sharing magic going on between those 
> per-process archives?
>
> (i suppose you could just use the dynamic CDS feature once and use the 
> dynamic archive just like it would be a second static & shareable 
> archive)
>
> best regards,
> michael
>
> On 25.04.19 23:26, mark.reinhold at oracle.com wrote:
>> The following JEP is proposed to target JDK 13:
>>
>>    350: Dynamic CDS Archives
>>         https://openjdk.java.net/jeps/350
>>
>> Feedback on this proposal from JDK Project Committers and Reviewers [1]
>> is more than welcome, as are reasoned objections.  If no such objections
>> are raised by 23:00 UTC on Thursday, 2 May, or if they’re raised and
>> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
>> I’ll target this JEP to JDK 13.
>>
>> - Mark
>>
>>
>> [1] https://openjdk.java.net/census#jdk
>> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>
>



More information about the jdk-dev mailing list