2016-11-30 9 views
0

Я вызывал функцию «unsafe.allocateMemory» для большей части памяти из-за кучи. Но возвращаемое значение является нечетным.Что небезопасно.allocateMemory возвращается в Java

время выполнения среда показывает здесь:

Вот мой код:

import java.lang.reflect.Field; 
import sun.misc.Unsafe; 
public class UnsafeTest{ 
    public static void main(String[] args){ 
      try{ 
      Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe"); 
      theUnsafe.setAccessible(true); 
      Unsafe unsafe = (Unsafe) theUnsafe.get(null); 
      long addr = unsafe.allocateMemory(16); 
      System.out.println("the address is :"+addr); 
      unsafe.freeMemory(addr); 
      }catch(Exception e){ 
        System.out.println(e.getMessage()); 
      } 
    } 
} 

Результат:

Я думал, что что-то не так, потому что значение результата настолько больше, чем общий объем памяти (около 6G). Интересно, было ли значение адресом памяти? Если да, то как это можно выделить, поскольку на самом деле не так много памяти. Если нет, то какой базовый адрес памяти/кучи в ОС.

+0

http://hg.openjdk.java .net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/misc/Unsafe.java # l466 –

+2

Использование Unsafe предназначено только для продвинутого программирования на низком уровне. Я предлагаю вам не претендовать на это. – DwB

+0

https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details –

ответ

1

Unsafe#allocateMemory возвращает то, что называется "native pointer", который по существу является адрес в виртуальном пространстве памяти, связанное с процессом виртуальной машины Java. Операционная система и встроенный в CPU Memory Management Unit будут отвечать за сопоставление адресов в этом виртуальном пространстве с адресами в реальной физической памяти.

Поскольку адресное пространство является виртуальным, числовое значение внутри него не имеет никакого отношения к тому, сколько физической памяти доступно для системы: расположение виртуальной машины и адреса, возвращаемые из функций распределения памяти, находятся на усмотрении операционной системы и ее которые зависят от Java. ОС также должна учитывать hardware limitations, наложенную на виртуальное адресное пространство.

Смотрите также:

Кредиты: Комментарии оставленные @ Sotirios-delimanolis и @ klitos-Kyriacou

+0

Спасибо, @ anttix. Ваш ответ действительно помог мне. Я смешал виртуальную память с физической памятью. Но есть еще кое-что, о чем я запутался. Вы знаете, что с включенным сжатым Oops, как правило, память адресуется Word (64-разрядная), а не Byte, и мы можем получить сжатый адрес (32-разрядный) с адресом собственной виртуальной памяти, сдвинув 3 бит справа. Мы можем увидеть его из [link] (http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/ 9b0ca45cd756/src/share/vm/oops/oop.inline.hpp). Но в моем случае после тринадцатого биения значение еще больше, чем 2^32.Как java oops быть сжатым? –

+0

Я думаю, что ваше понимание сжатых oops немного неполно. Вот цитата из Oracle: «Сжатые oops представляют управляемые указатели как 32-битные смещения объекта из 64-разрядного базового адреса Java-кучи». Это упущение этого базового значения (64-битный адрес), который делает сжатые oops вписываются в 32 бита См. Http://stackoverflow.com/questions/25120546/trick-behind-jvms-compressed-oops – anttix

 Смежные вопросы

  • Нет связанных вопросов^_^