хроника-байты, поднимающие segfault

следуя принятому решению в chronicle-bytes shared DirectBytesStores, теперь я настроил свой код в том же путь к принятому ответу.

Я создаю 1 000 000 объектов, которые я записываю в MappedFile, и я хотел бы, чтобы каждый объект мог управлять своими собственными операциями чтения/записи в MappedFile:

public class DataObject {

    public static final int LENGTH = 12;
    private static final int A_OFFSET = 0;
    private static final int B_OFFSET = 4;

    private PointerBytesStore bytes;

    public DataObject(long memoryAddress) {
        this.bytes = new PointerBytesStore();
        this.bytes.set(memoryAddress, LENGTH)
    }

    public int getA() {
        return this.bytes.readInt(A_OFFSET);
    }

    public void setA(int a) {
        this.bytes.writeInt(a);
    }

    ...
}

Затем я создаю DataObject с помощью:

MappedFile file = MappedFile.mappedFile(new File(tmpfile), 64 << 10);
MappedBytes mappedBytes = MappedBytes.mappedBytes(mappedFile);
int offset = 0;
List<DataObject> myList = new ArrayList<>();
for(i = 0; i < 1000000; i++) {
    int address = mappedBytes.addressForRead(offset);
    myList.add(new DataObject(address));
    offset += DataObject.LENGTH;
}

Я обнаружил, используя код, аналогичный приведенному выше, что Chronicle-bytes генерирует segfault, как только я достигаю ~ 100 000 объектов. Segfault обычно возникает при попытке чтения или записи в PointerBytesStore, но это непредсказуемо.

Это ошибка в хронике-байтах или я неправильно использую библиотеку? Любая помощь/предложения/рекомендации будет принята с благодарностью.


person BackroomGibbon    schedule 22.10.2018    source источник


Ответы (1)


MappedFile сопоставляет куски памяти за раз. Если вы не сохраните эти фрагменты, зарезервировав их, память будет освобождена, когда они больше не будут использоваться.

Одним из решений является использование большого фрагмента, чтобы вы всегда использовали только один фрагмент.

Другой подход заключается в использовании карты хроник, так как она будет управлять памятью по мере необходимости.

person Peter Lawrey    schedule 23.10.2018
comment
Большой. Еще раз спасибо @Peter. Я посмотрю на это. - person BackroomGibbon; 24.10.2018