RFR: Here are some URLClassPath patches

[Paul Sandoz]

> On Feb 23, 2018, at 2:09 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> [+Paul]
> 
> On Fri, Feb 23, 2018 at 6:28 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> 8198484: URLClassPath should use an ArrayDeque instead of a Stack
>> http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-ArrayDeque/
>> https://bugs.openjdk.java.net/browse/JDK-8198484
> Can copyToArrayDeque use addAll?
> 


> On Feb 23, 2018, at 2:09 PM, Martin Buchholz <martinrb at google.com> wrote:

> Not directly, because addAll uses a lambda, and it's too early in the bootstrap for lambdas.
> 
> We could delambdafy ArrayDeque, plausibly because ArrayDeque is a super-core class, perhaps reengineering ArrayDeque(Collection) and/or addAll(Collection).
> 

Some data on how many lambdas/methods refs are used by the core collection classes could help. I would be wary of going on a lambda purge right now and biasing certain collection classes towards their use at startup if we can avoid that with careful management.

I would be tempted to drop the method copyToArrayDeque and just rely on the push method (even though it uses synchronized), then add a comment to the unopenedUrls field and/or in the constructor.


> Or perhaps lambda team has a plan to allow lambdas to be used in corest of core java sometime soon?

No current plans to more formally attack this gnarly problem. A start would be to gather data on the VM boot code-paths to better understand the sensitive areas, from that we might consider black listing some classes so a compiler failure is produced. IIRC the circularity errors can often confusing, it might be possible to place a check for the required VM init level, thereby producing a clearer runtime error. Lazier initialization might help too (i hope with constant dynamic stuff, where even though it’s using j.l.invoke it will move stuff off the critical path, while also spreading the cost of startup).

Paul.