The suggestion is to retain the idiom used in the SPARC implementation and re/introduce the interface (i.e. prefetch_copy_interval_in_bytes(), prefetch_scan_interval_in_bytes(), prefetch_fields_ahead(), allocate_prefetch_distance() and allocate_prefetch_style()) but make it private.
The rationale behind is as follows:
-- These prefetch settings (i.e. options and default values) are likely to change with different generations of the hardware, suggesting that we keep the hardware specific logic separated from the option handling (as much as possible), even when none or little logic is required.
-- We retain the idiom previously used, i.e. configuring a default value (-1) to mean we should provide a suitable default value (possibly by probing the hardware), allow the option/policy to be turned off (0) or accepting a command-line supplied value (>0).
The rationale behind is as follows:
-- These prefetch settings (i.e. options and default values) are likely to change with different generations of the hardware, suggesting that we keep the hardware specific logic separated from the option handling (as much as possible), even when none or little logic is required.
-- We retain the idiom previously used, i.e. configuring a default value (-1) to mean we should provide a suitable default value (possibly by probing the hardware), allow the option/policy to be turned off (0) or accepting a command-line supplied value (>0).
- clones
-
JDK-8182711 Re/Introduce private interface for HW-specific prefetch options in SPARC VM_Version.
-
- Resolved
-