On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <al...@openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which 
>> JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the 
>> loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and 
>> require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems 
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for 
>> zero and some of the other ports. Additional ports can be contributed via 
>> PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels 
>> have been trimmed down for now to hotspot, serviceability and core-libs. 
>> We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from 
>> Doug Lea's CVS. These changes will probably be proposed and integrated in 
>> advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support 
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to 
>> make life a bit easier and avoid having to separate VM changes and juggle 
>> branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains five additional 
> commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/lang/Thread.java line 602:

> 600:         } else {
> 601:             // getContextClassLoader not trusted
> 602:             ClassLoader cl = parent.contextClassLoader;

I might be misreading the comment on that line, but reading this if/else block 
a few times, I'm unsure what the expectations here are.

It's my understanding that a call to `getContextClassLoader()` can't be trusted 
if that method has been overridden by the passed `Thread` type. In such cases, 
we don't call that method and instead just use the field value of 
`contextClassLoader` (which is a private field on `Thread`). Is that 
understanding correct? If yes, then the condition in the `if` block a few lines 
above, looks odd. It seems to be calling the `getContextClassLoader()` if  that 
method is overridden by the passed `Thread` type, i.e. the untrusted case. 
Should it instead be:

if (sm == null || !isCCLOverridden(parent.getClass())) {
    return parent.getContextClassLoader();
}

(notice the negation)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

Reply via email to