Open cbridgha opened 1 year ago
@njr-11 and I were just discussing the use of synchronized
and he mentioned that after Virtual Threads are released synchronized
will still block platform threads. We should have a Story to examine uses of synchronized
to look for cases where performance could be improved by switching to locks instead.
Config tracking issue: https://github.com/OpenLiberty/open-liberty/issues/26000
API/SPI tracking issue: https://github.com/OpenLiberty/open-liberty/issues/25999
@cbridgha
Notes from the UFO Socialization:
enableManagedVT()
may need a different name, as it could affect threads other than just managed threads, e.g. EJB timers. Also the behaviour of this API is not yet fully defined. (renamed - and added error state detail... on slide 26)Pending Items before closure: 1) Perf team Blog on VT's. (Dec?) 2) Finish delivering Java 21 VT api fat bucket (Nov)
Pending Items before closure:
1. Perf team Blog on VT's. (Dec?) 2. Finish delivering Java 21 VT api fat bucket (Nov)
There is also this item, copied from our slack conversation: "ability to request the Liberty scheduled executor to run a scheduled task on a virtual thread instead of using a pooled platform thread"
Does this issue supersede https://github.com/OpenLiberty/open-liberty/issues/21034 ? @Thihup
What's the status of the adoption of Java 21 virtual threads in Open Liberty? Any news, plans, timelines? Thanks in advance!
Article: https://www.infoq.com/articles/java-virtual-threads-a-case-study/
Hopefully this ForkJoinPool fix in JDK 23 will result in improved numbers: https://bugs.openjdk.org/browse/JDK-8322732
Description
In addition to our normal JDK level 21 support, This feature will cover our internal changes taking advantage of Virtual Threads, (Primarily around our Executor service, and options to create VirtualThreads, instead of our normal platform threads through our managed thread pool). considerations to our customers expecting to use VT and expectation of our Executor's providing VT support.
Prototyping from the performance team is ongoing and findings will be feeding into recommendations for exploitation.
This also includes synchronization issues that could prevent users taking advantage.
Official JEP included for Java 21: https://openjdk.org/jeps/444
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Aha: Externally raised RFE (Aha)
UFO: Link to VT UFO
FTS: Link to Feature Test Summary GH Issue
Beta Blog: Link to Beta Blog Post GH Issue
GA Blog: Link to GA Blog Post GH Issue
Process Overview
Prioritization
Design
Implementation
Legal and Translation
Beta
GA
Other Deliverables
General Instructions
The process steps occur roughly in the order as presented. Process steps occasionally overlap.
Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").
Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.
If you need assistance, reach out to the OpenLiberty/release-architect.
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Prioritization
[ ] Feature added to the "New" column of the Open Liberty project board
[ ] Priority assigned
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Design Preliminaries
ID Required
, if non-trivial documentation needs to be created by the ID team.ID Required - Trivial
, if no design will be performed and only trivial ID updates are needed.Design
Design Review Request
Design Approval Request
Design Approved
No Design
No Design Approval Request
No Design Approved
Product Management Approval Request
and notifies OpenLiberty/product-managementProduct Management Approved
(OpenLiberty/product-management)FAT Documentation
[ ] "Feature Test Summary" child task created
Implementation
A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it
kind=noship
or beta fencing it.Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlined in the GA section.
Feature Development Begins
In Progress
labelLegal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.
Legal (Complete before Feature Complete Date)
Translation (Complete 1 week before Feature Complete Date)
Innovation (Complete 1 week before Feature Complete Date)
[ ] Consider whether any aspects of the feature may be patentable. If any identified, disclosures have been submitted.
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
kind=beta
,ibm:beta
,ProductInfo.getBetaEdition()
target:beta
and the appropriatetarget:YY00X-beta
(where YY00X is the targeted beta version).release:YY00X-beta
(where YY00X is the first beta version that included the functionality).Beta Blog (Complete 1.5 weeks before beta eGA)
[ ] Beta blog issue created and populated using the Open Liberty BETA blog post template.
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
target:ga
and the appropriatetarget:YY00X
(where YY00X is the targeted GA version).Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a
target:ga
label). GA of this feature may not occur until all approvals are obtained.All Features
focalApproved:externals
@OpenLiberty/demo-approvers Demo scheduled for EOI [Iteration Number]
to this issue.focalApproved:demo
.focalApproved:fat
.focalApproved:globalization
.Design Approved Features
focalApproved:accessibility
.focalApproved:id
.focalApproved:performance
.focalApproved:sve
.focalApproved:ste
.focalApproved:svt
.Remove Beta Fencing (Complete by Feature Complete Date)
GA Blog (Complete by Feature Complete Date)
Post GA
[ ] Replace
target:YY00X
label with the appropriaterelease:YY00X
. (OpenLiberty/release-manager)Other Deliverables
[ ] Standalone Feature Blog Post A blog post specifically about your feature or N/A. (OpenLiberty/release-architect)
[ ] OL Guides OL Guides assessment is complete or N/A. (OpenLiberty/guide-assessment)
[ ] Dev Experience Developer Experience & Tools work is complete or N/A. (OpenLiberty/dev-experience-assessment)