RFR: Small fixes - shipment one

Robbin Ehn rehn at openjdk.java.net
Tue Mar 22 15:30:04 UTC 2022


On Tue, 22 Mar 2022 14:51:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Reducing the number of variables, the number of assignment to each variable, white-spaces, renamed some variables, removed unnecessary template, etc...
>> Except the removal of template 'bottom', the code is the same. (assert is moved up one level)
>> 
>> Passes 1-3 (no new failures)
>> It seem to be slightly faster than before, but at least on par.
>> 
>> This is not complete at all, but to avoid merge conflict I want to ship, and also make someone happy about removing a template.
>
> src/hotspot/share/runtime/continuation.cpp line 1213:
> 
>> 1211: 
>> 1212:       chunk = allocate_chunk(cont_size + ContinuationHelper::frame_metadata);
>> 1213:       if (UNLIKELY(chunk == nullptr || !_thread->cont_fastpath() || _barriers)) { // OOME/probably humongous
> 
> This is just a strange set of conditions.  Why would you allocate_chunk if  _thread->cont_fastpath() is false? or _barriers, whatever that means.  Really don't expect a function like allocate_chunk to have side effects.
> Maybe in the latter two conditions, you still want to zero out the chunk in the tail and don't want to remove this.

The variable _barriers is set by allocate_chunk, so it must be check afterwards.
If allocation safepoints and there is JVM TI qeury it can 'remove' us as available for fastpath.
If allocation fails due to OOME.

The init_chunk() should always zero enought.

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

PR: https://git.openjdk.java.net/loom/pull/114


More information about the loom-dev mailing list