powered by simpleCommunicator - 2.0.38     © 2025 Programmizd 02
Форумы / Java [игнор отключен] [закрыт для гостей] / Java 8 - уже не совсем Java?
25 сообщений из 448, страница 15 из 18
Java 8 - уже не совсем Java?
    #39203733
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
К докладу Елизарова я-бы добавил годичной давности семинар по LMAX Disruptor.
Там тоже рассматривались общие вопросы оптимизации очередей и отдельно
кеши и выравнивание и работа GC.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39203757
chabapok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вроде где-то писали/говорили, что есть sun.misc.Contended для этого. Но использовать его стремно. Лучше б они сделали ее не в sun*. Вон пишут, что в девятке от unsafe хотят отказаться, и плюс Reflection.getCallerClass() тоже норовят грохнуть, помоему даже грохали. С этим Contended лучше не связываться, по возможности.

армы и x86 процессоров имеют по 64 байта кэшлайна. Насчет остальных архитектур - не знаю.
Данные выравнивают, хотя на x86 это необязательно, но это делают все равно - для унификации.

Насчет выпиливания полей - помоему это байка-страшилка. jvm позволяет подгружать классы. Где гарантия, что когда-нибудь кто-нибудь не попросит подгрузить класс, а этот класс не полезет в выпиленное поле? никаких ведь FieldSawOutException в этом случае не бросится! Значит и поле должно быть. И даже классы необязательно подгружать, потому что нет гарантий, что в это поле никто не полезет через рефлекшен. ИМХО, максимум что можно - это если сработал escape analyze, то не хранить такие поля в стеке. Но там тоже могут быть приколы с рефлекшеном, так что ИМХО, никакого выпиливания полей вообще не существует. Но инфа не 100%

забыл никЕсли честно я утерял нить спора
нет никакого спора
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39203758
chabapok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonгодичной давности семинар по LMAX Disruptor.
а где его взять?
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39203835
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_vladimirа в чем профит от аллокации на стеке, вместо аллокации в хипе?
Сборщиком мусора. Одна инструкция и память свободна. :)
Естественно если это не примитив и нужен деструктор все не так просто. :)
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39203841
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
chabapokmaytonгодичной давности семинар по LMAX Disruptor.
а где его взять?
Вроде это

YouTube Video
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204288
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей АрсеньевСборщиком мусора. Одна инструкция и память свободна. :)... ценой жёсткой связи порядка выделения и освобождения памяти.
Вы правда готовы работать при таких ограничениях?
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204330
just_vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наваял небольшой JMH бенчмарк, у меня вообще получается, что работа с массивом объектов идет даже быстрее, чем с массивом int'ов, при условии, что все объекты алоцированны подряд (почему пока не разобрался, нужно смотреть асемблерный код, а там на винде нужны лишние приседания для получения бинарника hsdis). Если же при наполнении массива параллельно создавать разные мусорные объекты, чтобы наши целевые объекты не занимали сплошной кусок памяти, то тогда уже начинается серьезная просадка по производительности.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204333
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Некоторые тезисы Елизарова я зафиксил на бумаге.
К сожалению перец очень быстро говорит и флудит
посторонними мыслями поэтому привожу не цитаты
а некоторые купированные фразы.

ЕлизаровGC

1. Идеальная ситуация - все объекты короткоживущие.
2. Долгоживущие объекты лежат корректируют
только примитивные поля или вообще не меняются.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204345
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЕлизаровGC
1. Идеальная ситуация - все объекты короткоживущие.
2. Долгоживущие объекты лежат корректируют
только примитивные поля или вообще не меняются.

Смотри. GC это всегда trade off
https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/tuning_tradeoffs.html
Короткоживущие объекты и перманентный Tenured это как раз способ избавиться от пауз в CMS. Но при этом максимальной производительности такой GC не даст.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204381
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_vladimirНаваял небольшой JMH бенчмарк, у меня вообще получается, что работа с массивом объектов идет даже быстрее, чем с массивом int'ов, при условии, что все объекты алоцированны подряд (почему пока не разобрался, нужно смотреть асемблерный код, а там на винде нужны лишние приседания для получения бинарника hsdis). Если же при наполнении массива параллельно создавать разные мусорные объекты, чтобы наши целевые объекты не занимали сплошной кусок памяти, то тогда уже начинается серьезная просадка по производительности.

???

Не верю ( C )

Код и что это за "работа" можно посмотреть.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204423
just_vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsevjust_vladimirНаваял небольшой JMH бенчмарк, у меня вообще получается, что работа с массивом объектов идет даже быстрее, чем с массивом int'ов, при условии, что все объекты алоцированны подряд (почему пока не разобрался, нужно смотреть асемблерный код, а там на винде нужны лишние приседания для получения бинарника hsdis). Если же при наполнении массива параллельно создавать разные мусорные объекты, чтобы наши целевые объекты не занимали сплошной кусок памяти, то тогда уже начинается серьезная просадка по производительности.

???

Не верю ( C )

Код и что это за "работа" можно посмотреть.
Да, конечно можно, вполне возможно я где то ошибся в тесте или неверно его интерпретирую или не учитываю влияние GC или еще что нибудь. Работа это сложение int'ов, сравнивал два кейса класс Foo, в нем 3 int'овых филда (a,b,c) и int'овый массив.

Код бенчмарка:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(value = 3, jvmArgsAppend = {"-XX:+UseParallelGC", "-Xms4g", "-Xmx4g"})
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class MyBenchmark {

    @Param({"10000"})
    int size;
	
	@Param({"0", "1000", "10000"})
    int trashSize;

    Foo[] objArr;
	Foo[][] objArrTrash;
	int[] intArr;

    @Setup
    public void setup() {
		
		objArr = new Foo[size];
		
		objArrTrash = new Foo[trashSize][size];
		
		intArr = new int[size * 3];
		for(int i = 0; i < size; i++){
			intArr[i * 3] = 1;
			intArr[i * 3 + 1] = 2;
			intArr[i * 3 + 2] = 3;
			
			objArr[i] = new Foo();
			
			for(int j = 0; j < trashSize; j++){
				objArrTrash[j][i] = new Foo();
			}
		}
    }

    @Benchmark
    public void objArray(Blackhole blackhole) {
		long total = 0;
		for(int i = 0; i < size; i++){
			Foo obj = objArr[i];
			total += obj.getA() + obj.getB() + obj.getC();
		}
		blackhole.consume(total);
    }
	
    @Benchmark
    public void intArray(Blackhole blackhole) {
		long total = 0;
		for(int i = 0; i < size; i++){
			total += intArr[i*3] + intArr[i*3 + 1] + intArr[i*3 + 2];
		}
		blackhole.consume(total);
    }
	
    public static class Foo {
		
		private int a;
		private int b;
		private int c;
		
		public int getA(){
			return this.a;
		}
		public int getB(){
			return this.b;
		}
		public int getC(){
			return this.c;
		}

		public Foo() {
			this.a = 1;
			this.b = 2;
			this.c = 3;
		}

		@Override
		public String toString() {
			return "Foo [a=" + a + ", b=" + b + ", c=" + c + "]";
		}

		@Override
		public int hashCode() {
			final int prime = 31;
			int result = 1;
			result = prime * result + a;
			result = prime * result + b;
			result = prime * result + c;
			return result;
		}

		@Override
		public boolean equals(Object obj) {
			if (this == obj)
				return true;
			if (obj == null)
				return false;
			if (getClass() != obj.getClass())
				return false;
			Foo other = (Foo) obj;
			if (a != other.a)
				return false;
			if (b != other.b)
				return false;
			if (c != other.c)
				return false;
			return true;
		}

	}

}



Что получилось на выходе:
jmh_outputBenchmark (size) (trashSize) Mode Samples Score Score error Units
MyBenchmark.intArray 10000 0 avgt 15 38352.732 996.941 ns/op
MyBenchmark.intArray 10000 1000 avgt 15 36765.030 2141.320 ns/op
MyBenchmark.intArray 10000 10000 avgt 15 34888.401 4205.767 ns/op
MyBenchmark.objArray 10000 0 avgt 15 26143.195 1200.436 ns/op
MyBenchmark.objArray 10000 1000 avgt 15 215898.867 19812.714 ns/op
MyBenchmark.objArray 10000 10000 avgt 15 106175.759 6576.237 ns/op


И чисто для objArray с разным trashSize:
jmh_outputBenchmark (size) (trashSize) Mode Samples Score Score error Units
MyBenchmark.objArray 10000 0 avgt 15 26862.265 1014.527 ns/op
MyBenchmark.objArray 10000 100 avgt 15 99337.478 5626.104 ns/op
MyBenchmark.objArray 10000 500 avgt 15 188794.983 17663.827 ns/op
MyBenchmark.objArray 10000 1000 avgt 15 217068.808 9772.326 ns/op
MyBenchmark.objArray 10000 2000 avgt 15 248142.848 6822.500 ns/op
MyBenchmark.objArray 10000 3000 avgt 15 251596.867 23983.232 ns/op
MyBenchmark.objArray 10000 5000 avgt 15 108882.238 4594.514 ns/op
MyBenchmark.objArray 10000 10000 avgt 15 104778.494 9427.842 ns/op


Буду рад, если кто-нибудь объяснит наблюдаемые эффекты:
1. Почему int array оказывается медленнее obj array, при условии удачной аллокации объектов?
2. Почему начиная с trashSize = 5000 (может чуть раньше) скорость начинает расти?
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204431
just_vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ах да:
java - versionjava version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

verMicrosoft Windows [Version 6.3.9600]

hardwareCore i5 - 2400 3,3 Ghz, L1 - 256 kb, L2 - 1Mb, L3 - 6Mb
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204483
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IMHO Вы просто не умеете их готовить.

p.s. сейчас с тестом поиграюсь, хотя параметры подсократил. У меня AMD, ждать > 5 мин. на тест - перебор
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204495
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
package my.my1;

import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.infra.Blackhole;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
import java.util.concurrent.TimeUnit;

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(value = 3, jvmArgsAppend = {"-XX:+UseParallelGC", "-Xms4g", "-Xmx4g"})
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class MyBenchmark {
	
    @Param({"10000"})
    int size;
	
//	Param({"0", "1000", "10000"})
	@Param({"0"})
    int trashSize;

    Foo[] objArr;
	Foo[][] objArrTrash;
	int[] intArr;

    @Setup
    public void setup() {
		
		objArr = new Foo[size];
		
		objArrTrash = new Foo[trashSize][size];
		
		intArr = new int[size * 3];
		for(int i = 0; i < size; i++){
			intArr[i * 3] = 1;
			intArr[i * 3 + 1] = 2;
			intArr[i * 3 + 2] = 3;
			
			objArr[i] = new Foo();
			
			for(int j = 0; j < trashSize; j++){
				objArrTrash[j][i] = new Foo();
			}
		}
    }

    @Benchmark
    public void objArray(Blackhole blackhole) {
		long total = 0;
		for(int i = 0; i < size; i++){
			Foo obj = objArr[i];
			total += obj.getA() + obj.getB() + obj.getC();
		}
		blackhole.consume(total);
    }
	
    @Benchmark
    public void intArray(Blackhole blackhole) {
		long total = 0;
		for(int i = 0; i < size; i++){
			total += intArr[i*3] + intArr[i*3 + 1] + intArr[i*3 + 2];
		}
		blackhole.consume(total);
    }

    @Benchmark
    public void intArray2(Blackhole blackhole) {
		long total = 0;
		// IMHO Правильно так
		for(int i = 0; i < intArr.length; i++){
			total += intArr[i];
		}
		blackhole.consume(total);
    }
	
    @Benchmark
    public void intArray3(Blackhole blackhole) {
		long total = 0;
		// IMHO Или, в крайнем случае, так
		for(int i = 0; i < intArr.length-2; i+=3 ){
			total += intArr[i+0] + intArr[i+1] + intArr[i+2];
		}
		blackhole.consume(total);
    }
	
    public static class Foo {
		
		private int a;
		private int b;
		private int c;
		
		public int getA(){
			return this.a;
		}
		public int getB(){
			return this.b;
		}
		public int getC(){
			return this.c;
		}

		public Foo() {
			this.a = 1;
			this.b = 2;
			this.c = 3;
		}

		@Override
		public String toString() {
			return "Foo [a=" + a + ", b=" + b + ", c=" + c + "]";
		}

		@Override
		public int hashCode() {
			final int prime = 31;
			int result = 1;
			result = prime * result + a;
			result = prime * result + b;
			result = prime * result + c;
			return result;
		}

		@Override
		public boolean equals(Object obj) {
			if (this == obj)
				return true;
			if (obj == null)
				return false;
			if (getClass() != obj.getClass())
				return false;
			Foo other = (Foo) obj;
			if (a != other.a)
				return false;
			if (b != other.b)
				return false;
			if (c != other.c)
				return false;
			return true;
		}

	}



	public static void main(String[] args) throws RunnerException {

		Options options = new OptionsBuilder()
				.include( MyBenchmark.class.getSimpleName() ).build();
		new Runner(options).run();
	}
}




Код: plaintext
1.
2.
3.
4.
5.
Benchmark              (size)  (trashSize)  Mode  Cnt      Score    Error  Units
MyBenchmark.intArray    10000            0  avgt   15  17796.849 ± 15.440  ns/op
MyBenchmark.intArray2   10000            0  avgt   15  12433.204 ± 10.562  ns/op
MyBenchmark.intArray3   10000            0  avgt   15   9869.107 ± 68.348  ns/op
MyBenchmark.objArray    10000            0  avgt   15  11780.634 ± 22.755  ns/op

Надеюсь в коде не ошибся. Вроде все 3-и методо intArrayN должны давать одинаковый результат. Не проверял.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204505
just_vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
ну кажется понял свою ошибку, что терял лишнее время на умножениях, из Ваших вариантов с intArray2 не совсем соглашусь, т.к. все таки надо двигаться по массиву честно по одному объекту, а вот intArray3 то что нужно.

А как на счет эффектов, когда при увеличении количества мусорных объектов скорость растет, вместо ожидаемого падения?
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204524
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_vladimirLeonid Kudryavtsev,
ну кажется понял свою ошибку, что терял лишнее время на умножениях, из Ваших вариантов с intArray2 не совсем соглашусь, т.к. все таки надо двигаться по массиву честно по одному объекту, а вот intArray3 то что нужно.

IMHO Дело не в умножении. А в оптимизации JIT проверки на выход за пределы массива
just_vladimirА как на счет эффектов, когда при увеличении количества мусорных объектов скорость растет, вместо ожидаемого падения?
А где она растет?

Мне вообще кажется, что там какие-то очень странные/случайные числа начинают генерироваться. Ну и мусору НУ ОЧЕНЬ много. Патерн > 5000 мусорных объектов на один рабочий - это какой-то трешь. Возможно сборщик мусора паралельно еще какую-то дефрагментацию проводит. До какого-то момента она не сказывается, потом начинает сказываться и ситуация немного улучшается (но все равно ЗНАЧИТЕЛЬНО ХУЖЕ /5 раз/, чем без мусора)

IMHO
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39204989
just_vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
соглашусь, что такое количество мусора перебор. И еще чуток по игрался с мусорными объектами, сделал с шагом в 500 от 0 до 10 000, получил следующую картинку:
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205006
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_vladimirполучил следующую картинку
График и цифры на нем наводят на воспоминания....
4000, 8000... ничего не напоминает?

4000 (правда байт) - размер Memory Page.

Фактически при таком кол-ве мусора, получается выравнивание объекта по Memory Page. Мусор оказывается в полностью неиспользуемых страницах, радостно "свопится" (не на диск, а в данном случае просто из кэша процессора или рабочего набора процесса) и больше не мешает )))

IMHO
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205013
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Факт интересный своей искусственностью. Но совершенно и 100% чистая синтетика. Никакого практического применения не имеет. IMHO
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205058
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хорошо-бы допилить некоторый хинт или ключевое слово языка.

К примеру я инстанциирую синглтон и заведомо знаю что он будет лежать в OldGen/Metaspace.

И я хочу заведомо подсказать аллокатору чтобы он не кидал этот объект в Eden
а сразу ложил туда куда мне нужно.

Код: java
1.
2.
3.
4.
5.
6.
7.
@OldGen
public static MaytonsFuckenSingleton getInstance(){
   if (inst==null){
     inst=new Maytons......();
   }
   return inst;
}


По сути на уровне разработки дать больше инструментов для управления аллокацией.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205078
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonК примеру я инстанциирую синглтон и заведомо знаю что он будет лежать в OldGen/Metaspace.
И я хочу заведомо подсказать аллокатору чтобы он не кидал этот объект в Eden

IMHO бессмысленный хинт. Экономия копеек. Eden и так крайне быстр.

Скорее надо наоборот, подсказка, что объект временный. Но тогда такую подсказку нужно будет у 99% объектов указывать, а это - треш и угар. Ну и разумеется, при недостатке памяти, у RunTime будет не богатый выбор: или падать с out of memory или все равно, не смотря на подсказку, в old вытеснить. Т.ч. тоже механика работы такой подсказки не понятна


Возможно, можно было бы на уровне VM сделать Thread кучи. Т.е. все объекты созданные в рамках Thread относятся к "своей" кучи. При смерти Thread или по каким-то событием (например, завершение обработки HTTP запроса в рамках Web/Application Сервера), выжившие объекты переносятся в Old, плюс чистится мусор относящийся к данному Thread в Old.

Получаем:
1. Для разных HTTP запросов (с разным временем выполнения) - можно сделать свою метрику обработки Eden области. Меньше сессионного мусора будет уходить в Old
2. Процесс можно осмысленно побить по кусочкам. Получим своего рода incremental mark sweep.
3. Потенциально, можно сделать 2-х уровневый Eden.
Если места в Eden Thread'а/HTTP-запроса мало, туда добавляются блоки из Old. Eden для конкретного Thread'а/HTTP-запроса расширяется.
По окончанию Thread'а/HTTP-запроса, вся область грохается, а выжившие объекты перемешаются в Old.

Нужно читать более подробно Читать:
1. о G1 garbage коллектор, вроде там похожая идея была.
2. как работает процесс пометки живой/мертвый объектов в Eden области. Х.з. Но minor GC крайне быстрый. Если пометка живой/мертвый в рамках привязки к Thread/HTTP-запросу можно сделать очень быстро, то осмысленно.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205094
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Развивая идею. Матричный Eden. Или сегментированный.

Поскольку чистка это в общем случае решение задачи из области теории графов
(проверка достижимости узлов из некого корня) то ее надо оптимизировать
исходя из сходных по своей природе узлов (объектов).

Например мы деаем какую-то активность. И много всего аллоцируем. А после
этого чистим всё. Чтобы не флудить в общем eden мы аллоцируем сегмент
и работаем в нем.

Во время фазы уборки GC учитывает наличие связей только внутри сегмента
и быстро убирает мусор не отвлекаясь на анализ всего графа. По сути
чистит подграф.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205126
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton...Во время фазы уборки GC учитывает наличие связей только внутри сегмента
и быстро убирает мусор не отвлекаясь на анализ всего графа. По сути
чистит подграф.
Не отвлекаться не может. Т.к. ссылки могли быть переданы в какой-то "глобальный" объект, и "только внутри" не получится. Но в случае с eden, он как-то такие ситуации разгуливает.

Вместо одного глобального eden, хочется много мелких "локальных". На уровне thread, http-запроса и т.д. В принципе, даже некоторые методы можно было бы помечать локально-эденистыми. Где известно, что будет идти большое выделение памяти внутри.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205130
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При этом minor (eden) GC вроде работает в параллельном режиме. Т.ч. даже VM на такую уборку можно не останавливать. А делать в параллель, в фоне.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39205131
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev
Возможно, можно было бы на уровне VM сделать Thread кучи. Т.е. все объекты созданные в рамках Thread относятся к "своей" кучи.

Так оно так и работает насколько я себя помню, у каждого Thread есть свой TLAB(thread local allocation buffer)
...
Рейтинг: 0 / 0
25 сообщений из 448, страница 15 из 18
Форумы / Java [игнор отключен] [закрыт для гостей] / Java 8 - уже не совсем Java?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]