Foliaダウンロード - Foliaソースコードのダウンロード

Folia

JAVAソースコード

1.0.0

ダウンロード

Fork of Paper は、専用サーバーに地域化されたマルチスレッドを追加します。

概要

Folia は、ロードされたチャンクの近くをグループ化して、「独立した領域」を形成します。 Folia が近くのチャンクをグループ化する方法の正確な詳細については、PaperMC のドキュメントを参照してください。それぞれの独立した領域には独自のティックループがあり、通常の Minecraft ティックレート (20TPS) でティックされます。ティックループはスレッドプール上で並行して実行されます。各領域には事実上、ティックループ全体を実行する独自の「メインスレッド」があるため、メインスレッドは存在しません。

多数のスプレッドプレーヤーを備えたサーバーの場合、Folia は多数のスプレッドリージョンを作成し、構成可能なサイズのスレッドプール上でそれらをすべて並行してチェックします。したがって、Folia はこのようなサーバーに対して適切に拡張できるはずです。

Folia も独自のプロジェクトであり、当面は Paper に統合されることはありません。

より詳細だが抽象的な概要: プロジェクトの概要。

よくある質問

Folia から恩恵を受けるサーバーの種類は何ですか?

Skyblock や SMP など、プレイヤーを自然に分散させるサーバータイプは、Folia から最も恩恵を受けます。サーバーにはかなりのプレイヤー数も必要です。

Folia はどのハードウェアで最適に動作しますか?

理想的には、少なくとも 16コア(スレッドではない)。

Folia を最適に構成するにはどうすればよいですか?

まず、必要なチャンクシステムワーカースレッドの数を大幅に減らすために、ワールドを事前に生成することをお勧めします。

以下は、Folia がリリースされる前に、ピーク時のプレイヤー数が約 330 人であったテストサーバーで実行されたテストに基づいた非常に大まかな推定です。したがって、これは正確ではなく、さらなる調整が必要になります。出発点として考えてください。

マシン上で利用可能なコアの合計数を考慮する必要があります。次に、以下にスレッドを割り当てます。

netty IO: 200 ～ 300 人のプレーヤーあたり最大 4
チャンクシステム IO スレッド: 200 ～ 300 人のプレーヤーあたり最大 3
チャンクシステムワーカー (事前に生成されている場合)、プレイヤー 200 ～ 300 人あたり最大 2 人
チャンクシステムワーカーが事前に生成されていない場合、最適な推測はありません。実行したテストサーバーでは 16 スレッドを与えましたが、プレイヤーが 300 人以下ではチャンクの生成が依然として遅かったからです。
GC 設定: ????ただし、GC 設定では同時スレッドが割り当てられるため、その数を正確に把握する必要があります。これは通常-XX:ConcGCThreads=nフラグを介して行われます。このフラグを-XX:ParallelGCThreads=nと混同しないでください。並列 GC スレッドはアプリケーションが GC によって一時停止されている場合にのみ実行されるため、考慮すべきではありません。

すべての割り当てが完了すると、80% の割り当て (割り当てられた合計スレッドが利用可能な CPU の 80% 未満) になるまでシステムに残っているコアを、ティックスレッド (グローバル設定の threaded-regions.threads の下) に割り当てることができます。

コアの 80% を超える割り当てをすべきではない理由は、プラグインやサーバーでさえ、構成できない、または予測できない追加のスレッドを使用する可能性があるためです。

さらに、上記はすべてプレイヤー数に基づく大まかな推測ですが、スレッドの割り当てが理想的ではない可能性が非常に高いため、最終的に表示されるスレッドの使用状況に基づいて調整する必要があります。

プラグインの互換性

もうメインスレッドはありません。 Folia で機能するには、存在するすべてのプラグインにある程度の変更が必要になると思います。さらに、あらゆる種類のマルチスレッドでは、プラグインが保持するデータに競合状態が発生する可能性があるため、必ず変更を加える必要があります。

したがって、互換性への期待は 0 にしてください。

APIプラン

現在、メインスレッドに依存する API が多数存在します。 Paper と互換性のあるプラグインは基本的に Folia と互換性があるとは考えていません。ただし、Folia プラグインを Paper と互換性を持たせる API を追加する計画があります。

たとえば、Bukkit スケジューラです。 Bukkit スケジューラは本質的に単一のメインスレッドに依存します。 Folia の RegionalScheduler と Folia の EntityScheduler を使用すると、リージョンが場所またはエンティティのいずれかを「所有」するときの「次のティック」までタスクをスケジュールできます。これらは、メインスレッドにスケジュールすることを除いて、通常の Paper で実装できます。どちらの場合も、タスクの実行は、場所またはエンティティを「所有」するスレッドで行われます。現在の Paper (シングルスレッド) は、すべての世界のすべてのチャンクを含む 1 つの巨大な「領域」とみなすことができるため、この概念は一般的に当てはまります。

この API を Paper 自体に直接追加するか、Paperlib に追加するかはまだ決まっていません。

新しいルール

まず、Folia は多くのプラグインを破壊します。ユーザーがどのプラグインが動作するかを判断しやすくするために、作成者によって Folia で動作するように明示的にマークされたプラグインのみがロードされます。プラグインの plugin.yml に「folia-supported: true」を設定することで、プラグイン作成者は、プラグインを地域化されたマルチスレッドと互換性があるものとしてマークできます。

もう 1 つの重要なルールは、領域が同時にではなく、並行して動くということです。彼らはデータを共有せず、データを共有することを期待していません。データを共有するとデータ破損が発生します。あるリージョンで実行されているコードは、いかなる状況であっても、別のリージョンにあるデータにアクセスしたり、データを変更したりすることはできません。名前にマルチスレッドが含まれているからといって、すべてがスレッドセーフになるわけではありません。実際、これを実現するためにスレッドセーフになっているものはほんのわずかです。時間が経つにつれて、たとえパフォーマンスが犠牲になるとしても、スレッドコンテキストチェックの数は増加する一方です。バグだらけのサーバープラットフォームを使用したり開発したりする人は誰もいないでしょうし、これを防止して見つける唯一の方法はありません。バグは、不正なアクセスがその原因で失敗するようにすることです。

これは、Folia 互換プラグインが、コードが正しいスレッドコンテキストで実行されていることを確認するために、RegionScheduler や EntityScheduler などの API を利用する必要があることを意味します。

一般に、リージョンはイベントのソースから約 8 チャンクのチャンクデータを所有していると想定して問題ありません (つまり、プレーヤーがブロックをブレイクすると、そのブロックの周囲の 8 チャンクにアクセスできる可能性があります)。ただし、これは保証されていません。プラグインは、正しい動作を保証するために、今後のスレッドチェック API を利用する必要があります。

スレッドセーフの唯一の保証は、単一のリージョンが特定のチャンク内のデータを所有しているという事実によって得られます。そのリージョンが動作している場合、そのリージョンはそのデータに完全にアクセスできます。このデータは具体的にはエンティティ/チャンク/ポイデータであり、プラグインデータとはまったく関係ありません。

通常のマルチスレッドルールは、プラグインが独自のデータや別のプラグインのデータを保存/アクセスするデータ (イベント/コマンドなど) に適用されます。リージョンは並行して動作するため、並行して呼び出されます (デッドロックの問題が発生し、パフォーマンスが低下するため、同期的に呼び出すことはできません)。これを回避する簡単な方法はありません。それはアクセスされるデータによってのみ異なります。場合によっては、同時実行コレクション (ConcurrentHashMap など) で十分な場合もありますが、多くの場合、同時実行コレクションを不用意に使用すると、スレッドの問題が隠れるだけになり、デバッグがほぼ不可能になります。

現在の API の追加

API の追加を正しく理解するには、プロジェクトの概要をお読みください。

RegionScheduler、AsyncScheduler、GlobalRegionScheduler、および BukkitScheduler の代替として機能する EntityScheduler。エンティティスケジューラは Entity#getScheduler を介して取得され、残りのスケジューラは Bukkit/Server クラスから取得できます。
現在のティック領域が位置/エンティティを所有しているかどうかをテストする Bukkit#isOwnedByCurrentRegion

APIのスレッドコンテキスト

API の追加を正しく理解するには、プロジェクトの概要をお読みください。

一般的な経験則:

エンティティ/プレーヤーのコマンドは、エンティティ/プレーヤーを所有する領域で呼び出されます。コンソールコマンドはグローバルリージョンで実行されます。
単一のエンティティに関係するイベント (つまり、プレーヤーがブロックを中断/配置する) は、領域を所有するエンティティで呼び出されます。エンティティに対するアクション (エンティティの損傷など) を伴うイベントは、ターゲットエンティティを所有するリージョンで呼び出されます。
イベントの async 修飾子は非推奨になりました。メインスレッドがなくなっても、リージョンまたはグローバルリージョンから起動されたすべてのイベントは同期とみなされます。

現在の壊れた API

ポータル、プレーヤーのリスポーン、一部のプレーヤーのログイン API と対話するほとんどの API が壊れています。
すべてのスコアボード API が壊れていると考えられます (これはグローバルな状態であり、適切に実装する方法がまだわかっていません)
ワールドロード/アンロード
エンティティ#テレポート。これはいかなる状況でも決して戻らないため、teleportAsync を使用してください
もっとできるかもしれない

計画されている API の追加

適切な非同期イベント。これにより、イベントの結果を後で別のスレッドコンテキストで完了できるようになります。これは、リージョン外のチャンクデータにアクセスするときに非同期チャンクロードが必要となるため、スポーン位置の選択などのいくつかの機能を実装するために必要です。
ワールドロード/アンロード
さらにここに来ます

計画された API の変更

全体的に非常に積極的なスレッドチェック。これは、プラグイン開発者が完全に診断できない方法でサーバーのランダムな部分をランダムに破壊する可能性のあるコードを配布することを防ぐために絶対に必要です。
さらにここに来ます

Maven 情報

Maven リポジトリ (folia-api 用):

< repository >
    < id >papermc</ id >
    < url >https://repo.papermc.io/repository/maven-public/</ url >
</ repository >

アーティファクト情報:

< dependency >
    < groupId >dev.folia</ groupId >
    < artifactId >folia-api</ artifactId >
    < version >1.20.1-R0.1-SNAPSHOT</ version >
    < scope >provided</ scope >
</ dependency >