개요
Skyframe StateMachine는 힙에 상주하는 해체된 함수 객체입니다. 필요한 값을 즉시 사용할 수 없지만 비동기적으로 계산하는 경우 중복 없이 유연한 평가를 지원합니다1. StateMachine는 대기하는 동안 스레드 리소스를 묶을 수 없으며 대신 일시중지했다가 재개해야 합니다. 따라서 재구성하면 이전 계산을 건너뛸 수 있도록 명시적 재진입 지점이 노출됩니다.
StateMachine는 시퀀스, 분기, 구조화된 논리적 동시성을 표현하는 데 사용할 수 있으며 Skyframe 상호작용에 맞게 특별히 조정됩니다. StateMachine는 더 큰 StateMachine로 구성될 수 있으며 하위 StateMachine를 공유할 수 있습니다. 동시성은 항상 구조적으로 계층적이며 순전히 논리적입니다. 모든 동시 하위 작업은 단일 공유 상위 SkyFunction 스레드에서 실행됩니다.
소개
이 섹션에서는 java.com.google.devtools.build.skyframe.state 패키지에 있는 StateMachine를 간단히 소개하고 그 필요성을 설명합니다.
Skyframe 재시작에 대한 간략한 소개
Skyframe은 종속 항목 그래프의 병렬 평가를 실행하는 프레임워크입니다.
그래프의 각 노드는 매개변수를 지정하는 SkyKey와 결과를 지정하는 SkyValue를 사용하여 SkyFunction을 평가하는 것과 상응합니다. 계산 모델은 SkyFunction이 SkyKey로 SkyValue를 조회하여 추가 SkyFunction의 재귀적 병렬 평가를 트리거할 수 있도록 합니다. 요청된 SkyValue가 계산의 일부 하위 그래프가 불완전하여 아직 준비되지 않은 경우 스레드를 묶는 차단 대신 요청하는 SkyFunction이 null getValue 응답을 관찰하고 SkyValue 대신 null를 반환하여 입력이 누락되어 불완전함을 나타내야 합니다.
이전에 요청된 모든 SkyValue가 사용 가능해지면 Skyframe이 SkyFunctions를 다시 시작합니다.
SkyKeyComputeState가 도입되기 전에는 다시 시작을 처리하는 기존 방식이 계산을 완전히 다시 실행하는 것이었습니다. 이 방법은 복잡도가 2차이지만, 다시 실행할 때마다 null를 반환하는 조회가 줄어들기 때문에 결국에는 완료됩니다. SkyKeyComputeState를 사용하면 손으로 지정된 체크포인트 데이터를 SkyFunction과 연결하여 상당한 재계산을 절약할 수 있습니다.
StateMachine는 SkyKeyComputeState 내부에 있는 객체로, 실행 일시 중지 및 재개 후크를 노출하여 SkyFunction이 다시 시작될 때 (SkyKeyComputeState가 캐시에서 벗어나지 않는다고 가정) 거의 모든 재계산을 제거합니다.
SkyKeyComputeState 내의 상태 저장 계산
객체 지향 설계 관점에서 순수 데이터 값 대신 SkyKeyComputeState 내부에 계산 객체를 저장하는 것이 좋습니다.
Java에서 동작 전달 객체의 최소 설명은 함수형 인터페이스이며 충분한 것으로 밝혀졌습니다. StateMachine에는 다음과 같은 재귀적 정의가 있습니다2.
@FunctionalInterface
public interface StateMachine {
StateMachine step(Tasks tasks) throws InterruptedException;
}
Tasks 인터페이스는 SkyFunction.Environment과 유사하지만 비동기성을 위해 설계되었으며 논리적으로 동시 실행되는 하위 작업3을 지원합니다.
step의 반환 값은 또 다른 StateMachine이므로 단계 시퀀스를 귀납적으로 지정할 수 있습니다. StateMachine이 완료되면 step은 DONE을 반환합니다. 예를 들면 다음과 같습니다.
class HelloWorld implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
System.out.println("hello");
return this::step2; // The next step is HelloWorld.step2.
}
private StateMachine step2(Tasks tasks) {
System.out.println("world");
// DONE is special value defined in the `StateMachine` interface signaling
// that the computation is done.
return DONE;
}
}
다음 출력을 사용하여 StateMachine를 설명합니다.
hello
world
step2가 StateMachine의 함수형 인터페이스 정의를 충족하므로 메서드 참조 this::step2도 StateMachine입니다. 메서드 참조는 StateMachine에서 다음 상태를 지정하는 가장 일반적인 방법입니다.
직관적으로 계산을 모놀리식 함수 대신 StateMachine 단계로 나누면 계산을 일시 중지하고 재개하는 데 필요한 후크가 제공됩니다. StateMachine.step가 반환되면 명시적인 정지 지점이 있습니다. 반환된 StateMachine 값으로 지정된 연속은 명시적 resume 지점입니다. 따라서 계산이 중단된 지점에서 정확히 다시 시작할 수 있으므로 재계산을 피할 수 있습니다.
콜백, 컨티뉴에이션, 비동기 컴퓨팅
기술적으로 말하면 StateMachine는 연속 역할을 하여 실행할 후속 계산을 결정합니다. 차단하는 대신 StateMachine는 step 함수에서 반환하여 자발적으로 정지할 수 있으며, 이렇게 하면 제어가 Driver 인스턴스로 다시 전달됩니다. 그러면 Driver가 준비된 StateMachine로 전환되거나 제어권을 Skyframe에 다시 넘길 수 있습니다.
기존에는 콜백과 컨티뉴에이션이 하나의 개념으로 혼동되었습니다.
하지만 StateMachine는 두 가지를 구분합니다.
- 콜백 - 비동기 계산 결과를 저장할 위치를 설명합니다.
- Continuation - 다음 실행 상태를 지정합니다.
비동기 작업을 호출할 때는 콜백이 필요합니다. 즉, SkyValue 조회와 같이 메서드를 호출할 때 실제 작업이 즉시 발생하지 않습니다. 콜백은 최대한 간단하게 유지해야 합니다.
컨티뉴에이션은 StateMachine의 StateMachine 반환 값이며 모든 비동기 계산이 해결된 후 이어지는 복잡한 실행을 캡슐화합니다. 이 구조화된 접근 방식을 사용하면 콜백의 복잡성을 관리할 수 있습니다.
작업
Tasks 인터페이스는 StateMachine에 SkyKey로 SkyValue를 조회하고 동시 하위 작업을 예약하는 API를 제공합니다.
interface Tasks {
void enqueue(StateMachine subtask);
void lookUp(SkyKey key, Consumer<SkyValue> sink);
<E extends Exception>
void lookUp(SkyKey key, Class<E> exceptionClass, ValueOrExceptionSink<E> sink);
// lookUp overloads for 2 and 3 exception types exist, but are elided here.
}
SkyValue 조회
StateMachine는 Tasks.lookUp 오버로드를 사용하여 SkyValue를 조회합니다. SkyFunction.Environment.getValue 및 SkyFunction.Environment.getValueOrThrow와 유사하며 예외 처리 시맨틱스가 비슷합니다. 이 구현은 조회를 즉시 실행하지 않고 대신 조회를 실행하기 전에 가능한 한 많은 조회를4 일괄 처리합니다. 값은 즉시 사용할 수 없을 수 있으므로(예: Skyframe 재시작 필요) 호출자는 콜백을 사용하여 결과 값으로 무엇을 할지 지정합니다.
StateMachine 프로세서 (Driver 및 SkyFrame으로 브리징)는 다음 상태가 시작되기 전에 값을 사용할 수 있도록 보장합니다. 예시는 다음과 같습니다.
class DoesLookup implements StateMachine, Consumer<SkyValue> {
private Value value;
@Override
public StateMachine step(Tasks tasks) {
tasks.lookUp(new Key(), (Consumer<SkyValue>) this);
return this::processValue;
}
// The `lookUp` call in `step` causes this to be called before `processValue`.
@Override // Implementation of Consumer<SkyValue>.
public void accept(SkyValue value) {
this.value = (Value)value;
}
private StateMachine processValue(Tasks tasks) {
System.out.println(value); // Prints the string representation of `value`.
return DONE;
}
}
위의 예에서 첫 번째 단계는 new Key()을 조회하여 this을 소비자로 전달합니다. 이는 DoesLookup가 Consumer<SkyValue>를 구현하기 때문에 가능합니다.
계약에 따라 다음 상태 DoesLookup.processValue가 시작되기 전에 DoesLookup.step의 모든 조회가 완료됩니다. 따라서 processValue에서 액세스하면 value를 사용할 수 있습니다.
하위 할 일
Tasks.enqueue는 논리적으로 동시인 하위 작업의 실행을 요청합니다.
하위 작업도 StateMachine이며, 정규 StateMachine가 할 수 있는 모든 작업을 할 수 있습니다. 여기에는 하위 작업을 재귀적으로 만들거나 SkyValue를 조회하는 작업이 포함됩니다.
lookUp와 마찬가지로 상태 머신 드라이버는 다음 단계로 진행하기 전에 모든 하위 작업이 완료되었는지 확인합니다. 예시는 다음과 같습니다.
class Subtasks implements StateMachine {
private int i = 0;
@Override
public StateMachine step(Tasks tasks) {
tasks.enqueue(new Subtask1());
tasks.enqueue(new Subtask2());
// The next step is Subtasks.processResults. It won't be called until both
// Subtask1 and Subtask 2 are complete.
return this::processResults;
}
private StateMachine processResults(Tasks tasks) {
System.out.println(i); // Prints "3".
return DONE; // Subtasks is done.
}
private class Subtask1 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
i += 1;
return DONE; // Subtask1 is done.
}
}
private class Subtask2 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
i += 2;
return DONE; // Subtask2 is done.
}
}
}
Subtask1와 Subtask2는 논리적으로 동시 실행되지만 모든 것이 단일 스레드에서 실행되므로 i의 '동시' 업데이트에는 동기화가 필요하지 않습니다.
구조화된 동시 실행
다음 상태로 진행하기 전에 모든 lookUp와 enqueue가 해결되어야 하므로 동시성은 자연스럽게 트리 구조로 제한됩니다. 다음 예와 같이 계층적5 동시성을 만들 수 있습니다.
동시 실행 구조가 트리를 형성한다는 것을 UML에서 알기는 어렵습니다. 트리 구조를 더 잘 보여주는 대체 보기가 있습니다.
구조화된 동시 실행은 추론하기가 훨씬 쉽습니다.
컴포지션 및 제어 흐름 패턴
이 섹션에서는 여러 StateMachine를 구성하는 방법과 특정 제어 흐름 문제에 대한 해결 방법을 보여줍니다.
순차적 상태
가장 일반적이고 간단한 제어 흐름 패턴입니다. 이 예는 SkyKeyComputeState 내의 상태 저장 계산에 나와 있습니다.
브랜칭
StateMachine의 분기 상태는 다음 예와 같이 일반적인 Java 제어 흐름을 사용하여 다른 값을 반환하여 달성할 수 있습니다.
class Branch implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
// Returns different state machines, depending on condition.
if (shouldUseA()) {
return this::performA;
}
return this::performB;
}
…
}
특정 브랜치가 조기 완료를 위해 DONE를 반환하는 것은 매우 흔한 일입니다.
고급 순차적 구성
StateMachine 제어 구조는 메모리가 없으므로 StateMachine 정의를 하위 작업으로 공유하는 것이 어색할 수 있습니다. M1과 M2가 StateMachine을 공유하는 StateMachine 인스턴스라고 하고 M1과 M2가 각각 <A, S, B> 및 <X, S, Y> 시퀀스라고 가정합니다. 문제는 S가 완료된 후 B로 계속할지 Y로 계속할지 알 수 없고 StateMachine가 호출 스택을 제대로 유지하지 않는다는 것입니다. 이 섹션에서는 이를 달성하기 위한 몇 가지 기법을 검토합니다.
StateMachine를 종결 시퀀스 요소로 사용
이렇게 해도 제시된 초기 문제가 해결되지는 않습니다. 공유 StateMachine가 시퀀스에서 터미널인 경우에만 순차적 컴포지션을 보여줍니다.
// S is the shared state machine.
class S implements StateMachine { … }
class M1 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
performA();
return new S();
}
}
class M2 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
performX();
return new S();
}
}
S 자체가 복잡한 상태 머신인 경우에도 작동합니다.
순차 컴포지션의 하위 작업
대기열에 추가된 하위 작업은 다음 상태 전에 완료되므로 하위 작업 메커니즘을 약간 남용할 수 있습니다6.
class M1 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
performA();
// S starts after `step` returns and by contract must complete before `doB`
// begins. It is effectively sequential, inducing the sequence < A, S, B >.
tasks.enqueue(new S());
return this::doB;
}
private StateMachine doB(Tasks tasks) {
performB();
return DONE;
}
}
class M2 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
performX();
// Similarly, this induces the sequence < X, S, Y>.
tasks.enqueue(new S());
return this::doY;
}
private StateMachine doY(Tasks tasks) {
performY();
return DONE;
}
}
runAfter 삽입
S가 실행되기 전에 완료해야 하는 다른 병렬 하위 작업이나 Tasks.lookUp 호출이 있어 Tasks.enqueue를 악용할 수 없는 경우도 있습니다. 이 경우 runAfter 매개변수를 S에 삽입하여 다음에 무엇을 해야 하는지 S에 알릴 수 있습니다.
class S implements StateMachine {
// Specifies what to run after S completes.
private final StateMachine runAfter;
@Override
public StateMachine step(Tasks tasks) {
… // Performs some computations.
return this::processResults;
}
@Nullable
private StateMachine processResults(Tasks tasks) {
… // Does some additional processing.
// Executes the state machine defined by `runAfter` after S completes.
return runAfter;
}
}
class M1 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
performA();
// Passes `this::doB` as the `runAfter` parameter of S, resulting in the
// sequence < A, S, B >.
return new S(/* runAfter= */ this::doB);
}
private StateMachine doB(Tasks tasks) {
performB();
return DONE;
}
}
class M2 implements StateMachine {
@Override
public StateMachine step(Tasks tasks) {
performX();
// Passes `this::doY` as the `runAfter` parameter of S, resulting in the
// sequence < X, S, Y >.
return new S(/* runAfter= */ this::doY);
}
private StateMachine doY(Tasks tasks) {
performY();
return DONE;
}
}
이 접근 방식은 하위 작업을 남용하는 것보다 깔끔합니다. 하지만 runAfter로 여러 StateMachine를 중첩하는 등 너무 자유롭게 적용하면 콜백 지옥으로 이어집니다. 대신 일반적인 순차 상태로 순차 runAfter를 나누는 것이 좋습니다.
return new S(/* runAfter= */ new T(/* runAfter= */ this::nextStep))
다음으로 바꿀 수 있습니다.
private StateMachine step1(Tasks tasks) {
doStep1();
return new S(/* runAfter= */ this::intermediateStep);
}
private StateMachine intermediateStep(Tasks tasks) {
return new T(/* runAfter= */ this::nextStep);
}
금지된 대체: runAfterUnlessError
이전 초안에서는 오류가 발생하면 일찍 중단되는 runAfterUnlessError를 고려했습니다. 이는 오류가 runAfter 참조가 있는 StateMachine에 의해 한 번, runAfter 머신 자체에 의해 한 번 등 두 번 확인되는 경우가 많다는 사실에 기반합니다.
숙고 끝에 오류 확인 중복 제거보다 코드의 균일성이 더 중요하다고 판단했습니다. runAfter 메커니즘이 항상 오류 검사가 필요한 tasks.enqueue 메커니즘과 일관된 방식으로 작동하지 않으면 혼동이 발생할 수 있습니다.
직접 위임
공식 상태 전환이 있을 때마다 기본 Driver 루프가 진행됩니다.
계약에 따라 상태를 진행하면 이전에 대기열에 추가된 모든 SkyValue 조회 및 하위 작업이 다음 상태가 실행되기 전에 해결됩니다. 위임자 StateMachine의 논리로 인해 단계 진행이 불필요하거나 역효과를 내는 경우가 있습니다. 예를 들어 위임된 상태의 조회와 병렬화될 수 있는 SkyKey 조회를 위임의 첫 번째 step에서 실행하는 경우 단계 진행으로 인해 순차적으로 실행됩니다. 아래 예와 같이 직접 위임을 실행하는 것이 더 합리적일 수 있습니다.
class Parent implements StateMachine {
@Override
public StateMachine step(Tasks tasks ) {
tasks.lookUp(new Key1(), this);
// Directly delegates to `Delegate`.
//
// The (valid) alternative:
// return new Delegate(this::afterDelegation);
// would cause `Delegate.step` to execute after `step` completes which would
// cause lookups of `Key1` and `Key2` to be sequential instead of parallel.
return new Delegate(this::afterDelegation).step(tasks);
}
private StateMachine afterDelegation(Tasks tasks) {
…
}
}
class Delegate implements StateMachine {
private final StateMachine runAfter;
Delegate(StateMachine runAfter) {
this.runAfter = runAfter;
}
@Override
public StateMachine step(Tasks tasks) {
tasks.lookUp(new Key2(), this);
return …;
}
// Rest of implementation.
…
private StateMachine complete(Tasks tasks) {
…
return runAfter;
}
}
데이터 흐름
이전 논의에서는 제어 흐름 관리에 중점을 두었습니다. 이 섹션에서는 데이터 값의 전파를 설명합니다.
Tasks.lookUp 콜백 구현
SkyValue 조회에 Tasks.lookUp 콜백 구현 예가 있습니다. 이 섹션에서는 여러 SkyValue를 처리하는 근거와 방법을 제안합니다.
Tasks.lookUp 콜백
Tasks.lookUp 메서드는 콜백 sink를 매개변수로 사용합니다.
void lookUp(SkyKey key, Consumer<SkyValue> sink);
관용적인 접근 방식은 Java 람다를 사용하여 이를 구현하는 것입니다.
tasks.lookUp(key, value -> myValue = (MyValueClass)value);
여기서 myValue은 조회를 실행하는 StateMachine 인스턴스의 멤버 변수입니다. 하지만 람다는 StateMachine 구현에서 Consumer<SkyValue> 인터페이스를 구현하는 것보다 추가 메모리 할당이 필요합니다. 모호한 조회가 여러 개 있는 경우에도 람다는 여전히 유용합니다.
SkyFunction.Environment.getValueOrThrow과 유사한 Tasks.lookUp의 오류 처리 오버로드도 있습니다.
<E extends Exception> void lookUp(
SkyKey key, Class<E> exceptionClass, ValueOrExceptionSink<E> sink);
interface ValueOrExceptionSink<E extends Exception> {
void acceptValueOrException(@Nullable SkyValue value, @Nullable E exception);
}
구현 예는 아래와 같습니다.
class PerformLookupWithError extends StateMachine, ValueOrExceptionSink<MyException> {
private MyValue value;
private MyException error;
@Override
public StateMachine step(Tasks tasks) {
tasks.lookUp(new MyKey(), MyException.class, ValueOrExceptionSink<MyException>) this);
return this::processResult;
}
@Override
public acceptValueOrException(@Nullable SkyValue value, @Nullable MyException exception) {
if (value != null) {
this.value = (MyValue)value;
return;
}
if (exception != null) {
this.error = exception;
return;
}
throw new IllegalArgumentException("Both parameters were unexpectedly null.");
}
private StateMachine processResult(Tasks tasks) {
if (exception != null) {
// Handles the error.
…
return DONE;
}
// Processes `value`, which is non-null.
…
}
}
오류 처리가 없는 조회와 마찬가지로 StateMachine 클래스가 콜백을 직접 구현하면 람다의 메모리 할당이 저장됩니다.
오류 처리에서 좀 더 자세한 내용을 확인할 수 있지만 기본적으로 오류와 일반 값의 전파에는 큰 차이가 없습니다.
여러 SkyValue 사용
SkyValue 조회가 여러 번 필요한 경우가 많습니다. 대부분의 경우에 작동하는 방법은 SkyValue의 유형을 전환하는 것입니다. 다음은 프로토타입 프로덕션 코드에서 간소화된 예입니다.
@Nullable
private StateMachine fetchConfigurationAndPackage(Tasks tasks) {
var configurationKey = configuredTarget.getConfigurationKey();
if (configurationKey != null) {
tasks.lookUp(configurationKey, (Consumer<SkyValue>) this);
}
var packageId = configuredTarget.getLabel().getPackageIdentifier();
tasks.lookUp(PackageValue.key(packageId), (Consumer<SkyValue>) this);
return this::constructResult;
}
@Override // Implementation of `Consumer<SkyValue>`.
public void accept(SkyValue value) {
if (value instanceof BuildConfigurationValue) {
this.configurationValue = (BuildConfigurationValue) value;
return;
}
if (value instanceof PackageValue) {
this.pkg = ((PackageValue) value).getPackage();
return;
}
throw new IllegalArgumentException("unexpected value: " + value);
}
값 유형이 다르므로 Consumer<SkyValue> 콜백 구현을 명확하게 공유할 수 있습니다. 이러한 경우가 아니라면 적절한 콜백을 구현하는 람다 기반 구현이나 전체 내부 클래스 인스턴스로 대체하는 것이 좋습니다.
StateMachine 간 값 전파
지금까지 이 문서에서는 하위 작업에서 작업을 정렬하는 방법만 설명했지만 하위 작업은 호출자에게 값을 다시 보고해야 합니다. 하위 작업은 논리적으로 비동기적이므로 결과는 콜백을 사용하여 호출자에게 다시 전달됩니다. 이를 위해 하위 작업은 생성자를 통해 삽입되는 싱크 인터페이스를 정의합니다.
class BarProducer implements StateMachine {
// Callers of BarProducer implement the following interface to accept its
// results. Exactly one of the two methods will be called by the time
// BarProducer completes.
interface ResultSink {
void acceptBarValue(Bar value);
void acceptBarError(BarException exception);
}
private final ResultSink sink;
BarProducer(ResultSink sink) {
this.sink = sink;
}
… // StateMachine steps that end with this::complete.
private StateMachine complete(Tasks tasks) {
if (hasError()) {
sink.acceptBarError(getError());
return DONE;
}
sink.acceptBarValue(getValue());
return DONE;
}
}
호출자 StateMachine는 다음과 같습니다.
class Caller implements StateMachine, BarProducer.ResultSink {
interface ResultSink {
void acceptCallerValue(Bar value);
void acceptCallerError(BarException error);
}
private final ResultSink sink;
private Bar value;
Caller(ResultSink sink) {
this.sink = sink;
}
@Override
@Nullable
public StateMachine step(Tasks tasks) {
tasks.enqueue(new BarProducer((BarProducer.ResultSink) this));
return this::processResult;
}
@Override
public void acceptBarValue(Bar value) {
this.value = value;
}
@Override
public void acceptBarError(BarException error) {
sink.acceptCallerError(error);
}
private StateMachine processResult(Tasks tasks) {
// Since all enqueued subtasks resolve before `processResult` starts, one of
// the `BarResultSink` callbacks must have been called by this point.
if (value == null) {
return DONE; // There was a previously reported error.
}
var finalResult = computeResult(value);
sink.acceptCallerValue(finalResult);
return DONE;
}
}
위의 예에서는 몇 가지 사항을 보여줍니다. Caller는 결과를 다시 전파해야 하며 자체 Caller.ResultSink을 정의합니다. Caller는 BarProducer.ResultSink 콜백을 구현합니다. 재개 시 processResult는 value이 null인지 확인하여 오류가 발생했는지 확인합니다. 이는 하위 작업 또는 SkyValue 조회에서 출력을 수락한 후의 일반적인 동작 패턴입니다.
acceptBarError 구현은 오류 버블링에 따라 결과를 Caller.ResultSink에 적극적으로 전달합니다.
최상위 StateMachine의 대안은 Driver 및 SkyFunctions 브리징에 설명되어 있습니다.
오류 처리
Tasks.lookUp 콜백과 StateMachines 간 값 전파에 이미 오류 처리 예가 몇 개 있습니다. InterruptedException 이외의 예외는 발생하지 않고 콜백을 통해 값으로 전달됩니다. 이러한 콜백은 값 또는 오류 중 정확히 하나가 전달되는 배타적 OR 시맨틱을 갖는 경우가 많습니다.
다음 섹션에서는 Skyframe 오류 처리와의 미묘하지만 중요한 상호작용을 설명합니다.
오류 버블링 (--nokeep_going)
오류 버블링 중에 요청된 모든 SkyValue를 사용할 수 없더라도 SkyFunction이 다시 시작될 수 있습니다. 이러한 경우 Tasks API 계약으로 인해 후속 상태에 도달할 수 없습니다. 하지만 StateMachine은 예외를 전파해야 합니다.
전파는 다음 상태 도달 여부와 관계없이 발생해야 하므로 오류 처리 콜백이 이 작업을 실행해야 합니다. 내부 StateMachine의 경우 상위 콜백을 호출하여 이를 달성합니다.
SkyFunction과 인터페이스하는 최상위 StateMachine에서는 ValueOrExceptionProducer의 setException 메서드를 호출하여 이를 실행할 수 있습니다.
그런 다음 SkyValue가 누락된 경우에도 ValueOrExceptionProducer.tryProduceValue에서 예외를 발생시킵니다.
Driver가 직접 사용되는 경우 머신에서 처리를 완료하지 않았더라도 SkyFunction에서 전파된 오류를 확인해야 합니다.
이벤트 처리
이벤트를 내보내야 하는 SkyFunctions의 경우 StoredEventHandler가 SkyKeyComputeState에 삽입되고 이를 필요로 하는 StateMachine에 추가로 삽입됩니다. 이전에는 Skyframe이 특정 이벤트를 다시 재생하지 않으면 삭제했기 때문에 StoredEventHandler가 필요했지만 이후 이 문제가 수정되었습니다.
StoredEventHandler 삽입은 오류 처리 콜백에서 발생한 이벤트의 구현을 간소화하므로 유지됩니다.
Driver 및 SkyFunctions로 브리징
Driver는 지정된 루트 StateMachine부터 시작하여 StateMachine 실행을 관리합니다. StateMachine는 하위 작업 StateMachine를 재귀적으로 대기열에 추가할 수 있으므로 단일 Driver가 여러 하위 작업을 관리할 수 있습니다. 이러한 하위 작업은 구조화된 동시 실행의 결과인 트리 구조를 만듭니다. Driver는 효율성 향상을 위해 하위 작업 전반에서 SkyValue 조회를 일괄 처리합니다.
다음 API를 사용하여 Driver를 중심으로 빌드된 여러 클래스가 있습니다.
public final class Driver {
public Driver(StateMachine root);
public boolean drive(SkyFunction.Environment env) throws InterruptedException;
}
Driver는 단일 루트 StateMachine를 매개변수로 사용합니다. Driver.drive를 호출하면 Skyframe을 다시 시작하지 않고 최대한 StateMachine를 실행합니다. StateMachine가 완료되면 true를 반환하고 그렇지 않으면 false를 반환하여 일부 값을 사용할 수 없음을 나타냅니다.
Driver은 StateMachine의 동시 상태를 유지하며 SkyKeyComputeState에 삽입하는 데 적합합니다.
Driver를 직접 인스턴스화
StateMachine 구현은 일반적으로 콜백을 통해 결과를 전달합니다. 다음 예와 같이 Driver를 직접 인스턴스화할 수 있습니다.
Driver는 SkyKeyComputeState 구현에 삽입되며, 이에 상응하는 ResultSink의 구현은 조금 더 아래에 정의됩니다. 최상위 수준에서 State 객체는 Driver보다 오래 지속되므로 계산 결과를 수신하는 데 적합합니다.
class State implements SkyKeyComputeState, ResultProducer.ResultSink {
// The `Driver` instance, containing the full tree of all `StateMachine`
// states. Responsible for calling `StateMachine.step` implementations when
// asynchronous values are available and performing batched SkyFrame lookups.
//
// Non-null while `result` is being computed.
private Driver resultProducer;
// Variable for storing the result of the `StateMachine`
//
// Will be non-null after the computation completes.
//
private ResultType result;
// Implements `ResultProducer.ResultSink`.
//
// `ResultProducer` propagates its final value through a callback that is
// implemented here.
@Override
public void acceptResult(ResultType result) {
this.result = result;
}
}
아래 코드는 ResultProducer를 스케치합니다.
class ResultProducer implements StateMachine {
interface ResultSink {
void acceptResult(ResultType value);
}
private final Parameters parameters;
private final ResultSink sink;
… // Other internal state.
ResultProducer(Parameters parameters, ResultSink sink) {
this.parameters = parameters;
this.sink = sink;
}
@Override
public StateMachine step(Tasks tasks) {
… // Implementation.
return this::complete;
}
private StateMachine complete(Tasks tasks) {
sink.acceptResult(getResult());
return DONE;
}
}
그러면 결과를 지연 계산하는 코드는 다음과 같습니다.
@Nullable
private Result computeResult(State state, Skyfunction.Environment env)
throws InterruptedException {
if (state.result != null) {
return state.result;
}
if (state.resultProducer == null) {
state.resultProducer = new Driver(new ResultProducer(
new Parameters(), (ResultProducer.ResultSink)state));
}
if (state.resultProducer.drive(env)) {
// Clears the `Driver` instance as it is no longer needed.
state.resultProducer = null;
}
return state.result;
}
임베딩 Driver
StateMachine가 값을 생성하고 예외를 발생시키지 않는 경우 다음 예와 같이 Driver을 삽입하는 것도 가능한 구현입니다.
class ResultProducer implements StateMachine {
private final Parameters parameters;
private final Driver driver;
private ResultType result;
ResultProducer(Parameters parameters) {
this.parameters = parameters;
this.driver = new Driver(this);
}
@Nullable // Null when a Skyframe restart is needed.
public ResultType tryProduceValue( SkyFunction.Environment env)
throws InterruptedException {
if (!driver.drive(env)) {
return null;
}
return result;
}
@Override
public StateMachine step(Tasks tasks) {
… // Implementation.
}
SkyFunction에는 다음과 같은 코드가 있을 수 있습니다 (여기서 State은 SkyKeyComputeState의 함수별 유형임).
@Nullable // Null when a Skyframe restart is needed.
Result computeResult(SkyFunction.Environment env, State state)
throws InterruptedException {
if (state.result != null) {
return state.result;
}
if (state.resultProducer == null) {
state.resultProducer = new ResultProducer(new Parameters());
}
var result = state.resultProducer.tryProduceValue(env);
if (result == null) {
return null;
}
state.resultProducer = null;
return state.result = result;
}
StateMachine 구현에 Driver를 삽입하는 것이 Skyframe의 동기식 코딩 스타일에 더 적합합니다.
예외를 생성할 수 있는 StateMachine
그렇지 않으면 동기 SkyFunction 코드와 일치하는 동기 API가 있는 SkyKeyComputeState 삽입 가능 ValueOrExceptionProducer 및 ValueOrException2Producer 클래스가 있습니다.
ValueOrExceptionProducer 추상 클래스에는 다음 메서드가 포함됩니다.
public abstract class ValueOrExceptionProducer<V, E extends Exception>
implements StateMachine {
@Nullable
public final V tryProduceValue(Environment env)
throws InterruptedException, E {
… // Implementation.
}
protected final void setValue(V value) { … // Implementation. }
protected final void setException(E exception) { … // Implementation. }
}
여기에는 삽입된 Driver 인스턴스가 포함되며 삽입 드라이버의 ResultProducer 클래스와 매우 유사하고 유사한 방식으로 SkyFunction과 인터페이스합니다. ResultSink를 정의하는 대신 이러한 이벤트가 발생하면 구현에서 setValue 또는 setException를 호출합니다.
두 가지 모두 발생하는 경우 예외가 우선합니다. tryProduceValue 메서드는 비동기 콜백 코드를 동기 코드에 연결하고 설정된 경우 예외를 발생시킵니다.
앞서 언급한 것처럼 오류 버블링 중에 일부 입력이 제공되지 않아 머신이 아직 완료되지 않은 경우에도 오류가 발생할 수 있습니다. 이를 수용하기 위해 tryProduceValue는 머신이 완료되기 전에도 설정된 예외를 발생시킵니다.
에필로그: 결국 콜백 삭제
StateMachine는 비동기 계산을 실행하는 매우 효율적이지만 상용구 집약적인 방법입니다. 연속 (특히 ListenableFuture에 전달된 Runnable 형식)은 Bazel 코드의 특정 부분에서 널리 사용되지만 분석 SkyFunction에서는 일반적이지 않습니다. 분석은 주로 CPU에 바인딩되어 있으며 디스크 I/O를 위한 효율적인 비동기 API가 없습니다. 결국 콜백은 학습 곡선이 있고 가독성을 저해하므로 콜백을 최적화하는 것이 좋습니다.
가장 유망한 대안 중 하나는 Java 가상 스레드입니다. 콜백을 작성할 필요가 없으며 모든 것이 동기식 차단 호출로 대체됩니다. 이는 플랫폼 스레드와 달리 가상 스레드 리소스를 묶는 것이 저렴해야 하기 때문입니다. 하지만 가상 스레드를 사용하더라도 간단한 동기 작업을 스레드 생성 및 동기화 기본 요소로 대체하는 것은 너무 비용이 많이 듭니다. StateMachine에서 Java 가상 스레드로 이전했는데, 속도가 훨씬 느려져 엔드 투 엔드 분석 지연 시간이 거의 3배 증가했습니다. 가상 스레드는 아직 미리보기 기능이므로 성능이 개선된 후에 이 이전이 실행될 수 있습니다.
Loom 코루틴이 제공된다면 이를 기다리는 것도 고려해 볼 수 있습니다. 여기서의 장점은 협력적 멀티태스킹을 사용하여 동기화 오버헤드를 줄일 수 있다는 것입니다.
다른 모든 방법이 실패하면 하위 수준 바이트 코드 재작성도 실행 가능한 대안이 될 수 있습니다. 충분히 최적화하면 손으로 작성한 콜백 코드에 가까운 성능을 달성할 수 있습니다.
부록
콜백 지옥
콜백 지옥은 콜백을 사용하는 비동기 코드에서 악명 높은 문제입니다. 이는 후속 단계의 연속이 이전 단계 내에 중첩되어 있기 때문입니다. 단계가 많으면 이 중첩이 매우 깊어질 수 있습니다. 제어 흐름과 결합하면 코드를 관리할 수 없게 됩니다.
class CallbackHell implements StateMachine {
@Override
public StateMachine step(Tasks task) {
doA();
return (t, l) -> {
doB();
return (t1, l2) -> {
doC();
return DONE;
};
};
}
}
중첩된 구현의 장점 중 하나는 외부 단계의 스택 프레임을 보존할 수 있다는 것입니다. Java에서 캡처된 람다 변수는 사실상 최종 변수여야 하므로 이러한 변수를 사용하는 것은 번거로울 수 있습니다. 다음과 같이 람다 대신 메서드 참조를 연속으로 반환하여 깊은 중첩을 방지합니다.
class CallbackHellAvoided implements StateMachine {
@Override
public StateMachine step(Tasks task) {
doA();
return this::step2;
}
private StateMachine step2(Tasks tasks) {
doB();
return this::step3;
}
private StateMachine step3(Tasks tasks) {
doC();
return DONE;
}
}
runAfter 삽입 패턴을 너무 많이 사용하면 콜백 지옥이 발생할 수도 있지만, 순차적 단계와 함께 삽입을 사용하면 이를 방지할 수 있습니다.
예: 연결된 SkyValue 조회
애플리케이션 로직에 종속된 SkyValue 조회 체인이 필요한 경우가 많습니다(예: 두 번째 SkyKey가 첫 번째 SkyValue에 종속된 경우). 이를 단순하게 생각하면 복잡하고 깊이 중첩된 콜백 구조가 됩니다.
private ValueType1 value1;
private ValueType2 value2;
private StateMachine step1(...) {
tasks.lookUp(key1, (Consumer<SkyValue>) this); // key1 has type KeyType1.
return this::step2;
}
@Override
public void accept(SkyValue value) {
this.value1 = (ValueType1) value;
}
private StateMachine step2(...) {
KeyType2 key2 = computeKey(value1);
tasks.lookup(key2, this::acceptValueType2);
return this::step3;
}
private void acceptValueType2(SkyValue value) {
this.value2 = (ValueType2) value;
}
하지만 연속은 메서드 참조로 지정되므로 상태 전환 전반에 걸쳐 코드가 절차적으로 보입니다. step2가 step1를 따릅니다. 여기서는 람다를 사용하여 value2를 할당합니다. 이렇게 하면 코드의 순서가 위에서 아래로 계산되는 순서와 일치합니다.
기타 도움말
가독성: 실행 순서
가독성을 높이려면 StateMachine.step 구현을 실행 순서대로 유지하고 콜백 구현은 코드에서 전달되는 위치 바로 뒤에 오도록 하세요. 제어 흐름이 분기되는 경우에는 항상 가능한 것은 아닙니다. 이러한 경우 추가 의견이 도움이 될 수 있습니다.
예: 연결된 SkyValue 조회에서는 이를 위해 중간 메서드 참조가 생성됩니다. 이렇게 하면 가독성을 위해 약간의 성능이 희생되지만 여기서는 그만한 가치가 있습니다.
세대별 가설
수명이 중간인 Java 객체는 Java 가비지 수집기의 세대 가설을 깨뜨립니다. 이 가비지 수집기는 수명이 매우 짧은 객체나 수명이 영원한 객체를 처리하도록 설계되었습니다. 정의에 따라 SkyKeyComputeState의 객체는 이 가설을 위반합니다. Driver을 루트로 하여 아직 실행 중인 모든 StateMachine의 구성된 트리를 포함하는 이러한 객체는 비동기 계산이 완료되기를 기다리면서 일시 중단되므로 중간 수명을 갖습니다.
JDK19에서는 덜 심각한 것으로 보이지만 StateMachine를 사용하면 실제로 생성된 가비지가 크게 감소하더라도 GC 시간이 증가하는 것을 관찰할 수 있습니다. StateMachine의 수명이 중간 정도이므로 이전 세대로 승격되어 더 빨리 채워질 수 있으므로 정리하기 위해 더 비싼 메이저 또는 전체 GC가 필요합니다.
초기 예방 조치는 StateMachine 변수 사용을 최소화하는 것이지만, 여러 상태에서 값이 필요한 경우와 같이 항상 가능한 것은 아닙니다. 가능한 경우 로컬 스택 step 변수는 young generation 변수이며 효율적으로 GC됩니다.
StateMachine 변수의 경우 작업을 하위 작업으로 나누고 StateMachine 간에 값을 전파하는 데 권장되는 패턴을 따르는 것도 도움이 됩니다. 이 패턴을 따를 때 하위 StateMachine에만 상위 StateMachine에 대한 참조가 있고 그 반대는 아님을 확인하세요. 즉, 자녀가 결과 콜백을 사용하여 부모를 완료하고 업데이트하면 자녀가 범위에서 자연스럽게 벗어나 GC 대상이 됩니다.
마지막으로, 일부 경우에는 이전 상태에서는 StateMachine 변수가 필요하지만 이후 상태에서는 필요하지 않습니다. 더 이상 필요하지 않은 것으로 알려진 큰 객체의 참조를 null로 설정하는 것이 유익할 수 있습니다.
이름 지정 상태
메서드 이름을 지정할 때는 일반적으로 해당 메서드 내에서 발생하는 동작의 이름을 지정할 수 있습니다. 스택이 없으므로 StateMachine에서는 이 작업을 수행하는 방법이 명확하지 않습니다. 예를 들어 메서드 foo가 하위 메서드 bar를 호출한다고 가정해 보겠습니다. StateMachine에서는 이 상태가 foo 상태 시퀀스로 변환된 후 bar가 이어질 수 있습니다. foo에는 더 이상 bar 동작이 포함되지 않습니다. 따라서 상태의 메서드 이름은 범위가 좁은 경향이 있으며 로컬 동작을 반영할 수 있습니다.
동시 실행 트리 다이어그램
다음은 구조화된 동시 실행의 다이어그램을 트리 구조를 더 잘 보여주는 대체 뷰로 나타낸 것입니다. 블록이 작은 나무를 형성합니다.
-
값을 사용할 수 없는 경우 처음부터 다시 시작하는 Skyframe의 규칙과 대조됩니다. ↩
-
step는InterruptedException을 발생시킬 수 있지만 예에서는 이를 생략합니다. Bazel 코드에는 이 예외를 발생시키는 몇 가지 하위 메서드가 있으며, 이는 나중에 설명할StateMachine를 실행하는Driver까지 전파됩니다. 필요하지 않은 경우 예외가 발생한다고 선언하지 않아도 됩니다. ↩ -
동시 하위 작업은 각 종속 항목에 대해 독립적인 작업을 실행하는
ConfiguredTargetFunction에 의해 동기가 부여되었습니다. 모든 종속 항목을 한 번에 처리하는 복잡한 데이터 구조를 조작하여 비효율성을 도입하는 대신 각 종속 항목에는 자체 독립StateMachine가 있습니다. ↩ -
단일 단계 내의 여러
tasks.lookUp호출이 함께 일괄 처리됩니다. 동시 하위 작업 내에서 발생하는 조회를 통해 추가 일괄 처리를 만들 수 있습니다. ↩ -
이렇게 하는 것은 스레드를 생성하고 이를 조인하여 순차적 구성을 달성하는 것과 유사합니다. ↩