Почему в этой разборке стек увеличивается на 16 байт, когда у меня есть только одна 4-байтовая локальная переменная?

Взгляните на документацию @QueryParam в отношении допустимых типов для ввода. (То же самое относится ко всем остальным @XxxParam аннотации также)

  1. Быть примитивным типом
  2. Имейте конструктор, который принимает один аргумент String
  3. Имейте статический метод с именем valueOf или fromString, который принимает один аргумент String (см., Например, Integer.valueOf(String))
  4. Имеет зарегистрированную реализацию ParamConverterProvider JAX -RS extension SPI, который возвращает экземпляр ParamConverter , способный преобразовать «из строки» для этого типа.
  5. Be List, Set или SortedSet, где T удовлетворяет 2, 3 или 4 выше. Результирующий набор доступен только для чтения.

Причина этих требований заключается в том, что значение вводится как строка. Время выполнения должно знать, как преобразовать строку в тип для ввода. Причиной исключения является то, что при запуске есть первоначальная проверка модели ресурса. Эта проверка проверяет, действительно ли все точки инъекции действительны. Он видит, что введенный тип MyRequest не отвечает ни одному из вышеуказанных требований и выдает исключение.

В основном вы с точками 2 и 3, вам нужно будет самостоятельно разобрать строку, например

public class MyRequest {
    public static MyRequest fromString(string param) {
        // 1. Parse string
        // 2. Create MyRequest request;
        return request;
    }
}

Вы можете увидеть хороший пример использования ParamConverter здесь

1
задан araruna 16 January 2019 в 18:26
поделиться

2 ответа

Сегодня принято получать пространство стека кратным этому размеру по нескольким причинам:

  • строки кэша поддерживают это поведение, поддерживая все данные в кэше.
  • предварительно выделено место для временных файлов, избегая использования инструкций push и pop в случае необходимости некоторого временного хранения вне процессора.
  • отдельные команды push и pop ухудшают выполнение конвейера, требуя обновления данных перед выполнением следующей инструкции. Это разъединяет зависимости данных между последовательными инструкциями и позволяет им работать быстрее.

По этой причине фактические компиляторы указывают ABI, которые должны быть разработаны таким образом.

0
ответ дан Luis Colorado 16 January 2019 в 18:26
поделиться

Итак, по комментариям я мог понять, что проблема роста стека связана с требованиями i386 SystemV ABI, как заявлено @PeterCordes.

Причина, по которой символы выровнены по словам, может быть связана с поведением GCC по умолчанию для повышения скорости, как это можно сделать из комментария @ Ped7g. Хотя это и не определенно, это достаточно хороший ответ для меня.

0
ответ дан araruna 16 January 2019 в 18:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: