Помогите с проблемой запуске лаунчера майнкрафта.
[?:1.8.0_201]
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
[?:1.8.0_201]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[?:1.8.0_201]
> at java.lang.reflect.Method.invoke(Unknown Source)
[?:1.8.0_201]
> at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
> at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
> Caused by: java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method)
[?:1.8.0_201]
> at java.lang.Thread.start(Unknown Source)
[?:1.8.0_201]
> at java.util.concurrent.CompletableFuture$ThreadPerTaskExecutor.execute(Unknown Source)
[?:1.8.0_201]
> at java.util.concurrent.CompletableFuture.asyncRunStage(Unknown Source)
[?:1.8.0_201]
> at java.util.concurrent.CompletableFuture.runAsync(Unknown Source)
[?:1.8.0_201]
> at com.mojang.datafixers.DataFixerBuilder.build(DataFixerBuilder.java:70)
[DataFixerBuilder.class:?]
> at xz.b(SourceFile:140)
[xz.class:?]
> at xz.(SourceFile:135)
[xz.class:?]
> at aev$a.a(SourceFile:445)
[aev$a.class:?]
> at aev.a(SourceFile:131)
[aev.class:?]
> at aev.(SourceFile:137)
[aev.class:?]
> at pf.c(SourceFile:470)
[pf.class:?]
> at cft.(SourceFile:370)
[cft.class:?]
> at net.minecraft.client.main.Main.main(SourceFile:144)
и пишет еще:
Запустите эту версию еще раз, пока не пропадет это сообщение (около 1-7 попыток), TLaunher подберет подходящие настройка для вашей системы (это поможет помочь с запуском)!
Signature problem g1gc matches майнкрафт
Помогите расшифровать Crash report
WARNING: coremods are present:
DLFMLCorePlugin (DynamicLights_1.12.2.jar)
RenderPlayerAPIPlugin (RenderPlayerAPI-1.12.2-1.0.jar)
RBLoadingPlugin (RealBench_1.12.2_1.3.3.jar)
CXLibraryCore (cxlibrary-1.12.1-1.6.1.jar)
PlayerAPIPlugin (PlayerAPI_1.12.2_1.0.jar)
Contact their authors BEFORE contacting forge
// I bet Cylons wouldn’t have this problem.
Time: 6/4/20 8:50 PM
Description: Exception in server tick loop
java.lang.VerifyError: Inconsistent stackmap frames at branch target 47
Exception Details:
Location:
net/minecraft/world/World.func_175638_a(Lnet/minecraft/util/math/BlockPos;Lnet/m
inecraft/world/EnumSkyBlock;)I @32: goto
Reason:
Current frame’s stack size doesn’t match stackmap.
Current Frame:
bci: @32
flags: < >
locals: < 'net/minecraft/world/World', 'net/minecraft/util/math/BlockPos', 'net/minecraft/world/EnumSkyBlock', 'net/minecraft/block/state/IBlockState' >
stack: < integer >
Stackmap Frame:
bci: @47
flags: < >
locals: < 'net/minecraft/world/World', 'net/minecraft/util/math/BlockPos', 'net/minecraft/world/EnumSkyBlock', 'net/minecraft/block/state/IBlockState' >
stack: < top, integer >
Bytecode:
0x0000000: 2cb2 0281 a600 0e2a 2bb6 02fb 9900 0610
0x0000010: 0fac 2a2b b601 824e 2cb2 0281 a600 0703
0x0000020: a700 0f2d b901 9201 002d 2a2b b808 5b36
0x0000030: 042d b901 9201 002d 2a2b b602 fe36 0515
0x0000040: 0504 a200 0604 3605 1505 100f a100 0615
0x0000050: 04ac 1504 100e a100 0615 04ac b804 b13a
0x0000060: 06b8 085f 3a07 1907 be36 0803 3609 1509
0x0000070: 1508 a200 4a19 0715 0932 3a0a 1906 2bb6
0x0000080: 0865 190a b608 6957 2a2c 1906 b603 3415
0x0000090: 0564 360b 150b 1504 a400 0715 0b36 0415
0x00000a0: 0410 0ea1 0013 1504 360c 150c 360d 1906
0x00000b0: b604 bc15 0dac 8409 01a7 ffb5 1504 3607
0x00000c0: 1906 b604 bc15 07ac 3a0e 1906 b604 bc19
0x00000d0: 0ebf
Exception Handler Table:
bci [97, 174] => handler: 200
bci [182, 192] => handler: 200
bci [200, 202] => handler: 200
Stackmap Table:
same_frame(@18)
append_frame(@35,Object[#398])
full_frame(@47,
at net.minecraft.server.integrated.IntegratedServer.func_71247_a(IntegratedServer.j
ava:121)
at net.minecraft.server.integrated.IntegratedServer.func_71197_b(IntegratedServer.j
ava:156)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:486)
at java.lang.Thread.run(Thread.java:745)
| State | ID | Version | Source | Signature |
|:—— |:————————— |:—————— |:————————————- |:—————————————- |
| LCHIJA | minecraft | 1.12.2 | minecraft.jar | None |
| LCHIJA | mcp | 9.42 | minecraft.jar | None |
| LCHIJA | FML | 8.0.99.99 | forge-1.12.2-14.23.5.2854.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| LCHIJA | forge | 14.23.5.2854 | forge-1.12.2-14.23.5.2854.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| LCHIJA | PlayerAPI | 1.0 | minecraft.jar | None |
| LCHIJA | RenderPlayerAPI | 1.0 | minecraft.jar | None |
| LCHIJA | damageindicatorsmod | 1.0 | 1.12.2DamageIndicatorsMod_3.5.1.jar | None |
| LCHIJA | backpack | 3.0.2 | backpack_3.0.2_1.12.2.jar | None |
| LCHIJA | baubles | 1.5.2 | Baubles_1.12_1.5.2.jar | None |
| LCHIJA | bookshelf | 2.3.590 | Bookshelf_1.12.2_2.3.590.jar | d476d1b22b218a10d845928d1665d45fce301b27 |
| LCHIJA | cxlibrary | 1.6.1 | cxlibrary-1.12.1-1.6.1.jar | None |
| LCHIJA | dynamiclights | 1.4.8 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_onfire | 1.0.7 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_creepers | 1.0.6 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_dropitems | 1.1.0 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_entityclasses | 1.0.1 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_mobequipment | 1.1.0 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_flamearrows | 1.0.1 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_floodlights | 1.0.3 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_otherplayers | 1.0.9 | DynamicLights_1.12.2.jar | None |
| LCHIJA | dynamiclights_theplayer | 1.1.3 | DynamicLights_1.12.2.jar | None |
| LCHIJA | eplus | 5.0.178 | EnchantingPlus_1.12.2_5.0.178.jar | d476d1b22b218a10d845928d1665d45fce301b27 |
| LCHIJA | cfm | 6.3.0 | furniture_6.3.0_1.12.2.jar | None |
| LCHIJA | waila | 1.8.26 | Hwyla_1.8.26_B41_1.12.2.jar | None |
| LCHIJA | ic2 | 2.8.211-ex112 | industrialcraft_2_2.8.211_ex112.jar | de041f9f6187debbc77034a344134053277aa3b0 |
| LCHIJA | ironchest | 1.12.2-7.0.67.844 | ironchest_1.12.2_7.0.72.847.jar | None |
| LCHIJA | journeymap | 1.12.2-5.7.1 | journeymap_1.12.2_5.7.1.jar | None |
| LCHIJA | mantle | 1.12-1.3.3.55 | Mantle-1.12-1.3.3.55.jar | None |
| LCHIJA | millenaire | Millnaire 8.1.0 | millenaire_1.12.2_8.1.0.jar | None |
| LCHIJA | morefurnaces | 1.10.4 | MoreFurnaces-1.12.2-1.10.4.jar | None |
| LCHIJA | smartmoving | 16.4-RC3 | SmartMoving-1.12.2-16.4-RC3.jar | None |
| LCHIJA | smartrender | 2.3-RC2 | SmartRender-1.12.2-2.3-RC2.jar | None |
| LCHIJA | tconstruct | 1.12.2-2.13.0.183 | TConstruct-1.12.2-2.13.0.183.jar | None |
| LCHIJA | thaumcraft | 6.1.BETA26 | Thaumcraft_1.12.2_6.1.BETA26.jar | None |
| LCHIJA | wailaharvestability | 1.1.12 | WailaHarvestability_mc1.12_1.1.12.jar | None |
Loaded coremods (and transformers):
DLFMLCorePlugin (DynamicLights_1.12.2.jar)
atomicstryker.dynamiclights.common.DLTransformer
RenderPlayerAPIPlugin (RenderPlayerAPI-1.12.2-1.0.jar)
api.player.forge.RenderPlayerAPITransformer
RBLoadingPlugin (RealBench_1.12.2_1.3.3.jar)
pw.prok.realbench.asm.RBTransformer
CXLibraryCore (cxlibrary-1.12.1-1.6.1.jar)
cubex2.cxlibrary.CoreModTransformer
PlayerAPIPlugin (PlayerAPI_1.12.2_1.0.jar)
api.player.forge.PlayerAPITransformer
GL info:
RuntimeException: No OpenGL context found in the current thread.
Pulsar/tconstruct loaded Pulses:
— TinkerCommons (Enabled/Forced)
— TinkerWorld (Enabled/Not Forced)
— TinkerTools (Enabled/Not Forced)
— TinkerHarvestTools (Enabled/Forced)
— TinkerMeleeWeapons (Enabled/Forced)
— TinkerRangedWeapons (Enabled/Forced)
— TinkerModifiers (Enabled/Forced)
— TinkerSmeltery (Enabled/Not Forced)
— TinkerGadgets (Enabled/Not Forced)
— TinkerOredict (Enabled/Forced)
— TinkerIntegration (Enabled/Forced)
— TinkerFluids (Enabled/Forced)
— TinkerMaterials (Enabled/Forced)
— TinkerModelRegister (Enabled/Forced)
— wailaIntegration (Enabled/Not Forced)
Profiler Position: N/A (disabled)
Player Count: 0 / 8; []
Type: Integrated Server (map_client.txt)
Is Modded: Definitely; Client brand changed to ‘fml,forge’
astroxy77
краш при создание мира
Kozilok
FLYMAN12
WARNING: coremods are present:
MicdoodlePlugin (MicdoodleCore-1.12.2-4.0.1.181.jar)
TLSkinCapeHookLoader (tlskincape_1.12.2-1.4.jar)
Contact their authors BEFORE contacting forge
// I let you down. Sorry 🙁
Time: 7/29/20 10:21 AM
Description: Ticking entity
java.lang.ClassCastException: vazkii.botania.common.entity.EntitySpark cannot be cast to net.minecraft.entity.EntityLivingBase
at net.journey.entity.projectile.EntityFloroWater.func_70184_a(EntityFloroWater.jav
a:40)
at net.minecraft.entity.projectile.EntityThrowable.func_70071_h_(EntityThrowable.ja
va:249)
at net.journey.entity.projectile.EntityBasicProjectile.func_70071_h_(EntityBasicPro
jectile.java:35)
at net.journey.entity.projectile.EntityFloroWater.func_70071_h_(EntityFloroWater.ja
va:30)
at net.minecraft.world.World.func_72866_a(World.java:1996)
at net.minecraft.world.WorldServer.func_72866_a(WorldServer.java:832)
at net.minecraft.world.World.func_72870_g(World.java:1958)
at net.minecraft.world.World.func_72939_s(World.java:1762)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:613)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:767)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:668)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.j
ava:279)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526)
at java.lang.Thread.run(Unknown Source)
NullPointerException: null
Stacktrace:
at net.minecraft.world.World.func_72939_s(World.java:1762)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:613)
High memory consumption issue in G1GC
G1GC CONFIGURATIONS: The G1GC configuration now i used for my machine.
See also questions close to this topic
I can’t understand the logic sqrt method
I understand how to work code but the logic behind this code not
I’m scraping a web api with this Java code:
which throws a json that looks like this: https://pastebin.com/ZqqB5H8C
What I want to figure out is how to deserialize the json into a java object. This is the encapsulated bean I wrote to deserialize the json.
I was using try..finally code but I want to use try with resource but I am not sure how to call a method in try with resource can anyone help me with that?
using Try with resource
but I am not sure how should I call reportAbc() method without using finally.
this question may be too broad, so I understand if it needs to be closed.
I am an inexperienced cloud computing user. I have an optimization code where I parallelized some parts of the objective function. It runs fine in my computer, but it quickly makes my computer practically unusable due to how heavy it is. My computer is a Windows 10 with 16gb RAM. The code never crashes, just turns my computer sluggish. I even have 20+ google chrome tabs open.
At first, I created a Linux VM with 4 cores and 16GB ram, set everything up, and ran the code. It quickly ran out of memory and the program crashes. The serial code does not have this problem.
Then I thought that maybe Linux manages memory differently (I even dabbled with creating swap space), so I created a Windows server with also 4 cores and 16GB RAM. It also hits the RAM ceiling and the program crashes. When I added more RAM to the VM, it was able to progress.
My question is: Why does my computer with similar specs (and less ‘clean’) handles the program and manages the RAM, while a VM doesn’t do that? Why does this only happen with parallelized code? Is there something I should be configuring in these VM instances?
While I understand that being this vague may not be helpful, what I’m looking for is some general guidelines or paths that I should look into to understand why there are differences of memory management between my personal computer and a cloud VM.
I’m familiar with using a column- vs a row-store for how a databases internally persists data to disk. My question is whether, for a dataset is entirely in memory, and there’s no storage to disk, if the row- vs column- orientation makes much of a difference?
The only things I can think of that may make a difference would be:
Are both of those accurate, and are there any more? Given this, would there be substantial performance improvements on using an in-memory colstore vs rowstore on a read-only dataset, or just a marginal improvement?
When working with a large data set which takes up
10GB memory when loaded as a pandas DataFrame, I noticed that slicing it with booleans seemed to take up as much memory as making a copy, e.g.:
which supposedly returns a view of about half of the original DataFrame actually caused the memory usage to go up 50% to
15GB (using top to observe in real time).
If I only take a few rows with:
the memory footprint goes back down to 10GB.
Shouldn’t the slicing only return a view of the original DataFrame that doesn’t actually copy the underlying data? I guess I just don’t understand how DataFrame ‘views’ work. I thought it meant merely an indexing on the same underlying data store which should incur minimal overhead. Otherwise, what’s the point of the ‘views’ vs. ‘copies’?
In addition, I noticed that even when selecting a tiny slice, the first call momentarily doubles the memory usage to
20GB but then goes back down to
10GB. Subsequent calls do not incur this transient memory spike.
(pandas 0.23.4 on python 3.4.3)
Why does my garbage collector(G1 GC) do not release memory altough he could? The Used Heap is going up over time, the step fall at the end is because I forced the GC to release memory through jcmd
Why is that? Is that normal behaviour?
The only thing in logs are
Pause Young (Normal) (G1 Evacuation Pause)
Pause Young (Prepare Mixed) (G1 Evacuation Pause)
Pause Young (Mixed) (G1 Evacuation Pause)
Pause Young (Concurrent Start)
But nothing like Full GC. Not even once.
Memory usage is above 65 percent.
In my application I have implemented a background task which reads a JSON file to memory and parses it into Java objects of relevant (specified in JSON) classes. I use Jackson to parse JSON. The JSON file is about 6MB in size. My JSON files look more or less like this:
My background task runs every 30 minutes, and this is also where my JVM shows significantly big (up to 2 seconds) pause for garbage collection, which unfortunately impacts live traffic to my application. I am sure garbage collection pauses are related to JSON loading, because I compared task with JSON loading to the same task without. I have never attempted debugging such a thing before and I don’t quite know where to start.
I use Zulu 11 OpenJDK and G1 garbage collector.
Here are my questions:
Signature problem g1gc matches майнкрафт
Звание: Где-то рядом с нами
Привет всем. Вылетает Minecraft на любом лаунчере. Пробовал перезагружать пк и переустанавливать джаву. Помогите выяснить из-за чего вылетает Minecraft.
Vir2oZ
Eli_TO4ka
TheProFinch,
У меня вылезает подобная ошибка, помогите. что с этим сделать.
kemor_play
greenphl
WARNING: coremods are present:
Contact their authors BEFORE contacting forge
// Surprise! Haha. Well, this is awkward.
Time: 1/22/21 10:58 PM
Description: Exception ticking world
java.lang.NoSuchMethodError: net.minecraft.entity.EntityLiving$SpawnPlacementType.canSpawnAt(Lnet/minecraft/w
orld/World;Lnet/minecraft/util/math/BlockPos;)Z
at net.minecraft.world.WorldEntitySpawner.func_180267_a(WorldEntitySpawner.java:226
)
at net.minecraft.world.WorldEntitySpawner.func_77192_a(WorldEntitySpawner.java:135)
at net.minecraft.world.WorldServer.func_72835_b(WorldServer.java:203)
at WorldServerOF.func_72835_b(WorldServerOF.java:37)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:756)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:668)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.j
ava:239)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526)
at java.lang.Thread.run(Unknown Source)
at net.minecraft.world.WorldServer.func_72835_b(WorldServer.java:203)
at WorldServerOF.func_72835_b(WorldServerOF.java:37)
ModsMaxs
Звание: Где-то рядом с нами
Олег Май
kanobbe
minecraft.bedrock.govno
Недавно решил обновить Java. После этого майн перестал запускаться. Вот лог
RuntimeException: No OpenGL context found in the current thread.
GL Caps:
Using VBOs: No
Is Modded: Definitely; Client brand changed to ‘fml,forge’
Type: Client (map_client.txt)
Resource Packs:
Current Language:
Перекопал весь инет, все орут, что надо драйвера обновить. КАКИЕ НАХ*Й БЛ*ДЬ ДРАЙВЕРА С*КА, МОЕМУ ВИДЕОЯДРУ БЛ* ДОХ*Я БЛ*ДЬ ЛЕТ НАХ*Й, БОЛЬШЕ ЧЕМ ДЕДУ МОЕМУ НАХ*Й, ДРАЙВЕРА НА НЕЁ БЛ*ДЬ УЖЕ НЕСКОЛЬКО ЛЕТ НЕ ВЫХОДЯТ НАХ*Й, Я НЕ ХОЧУ ИЗЗА ПИЗД*ИГРЫ, КОТОРАЯ ДО П*ЗДЫ НЕОПТИМИЗИРОВАНА, НОВУЮ ВИДЮХУ БЛ*ДЬ ПОКУПАТЬ
(поясняю за базар: у меня тут просто бомбануло, извините, просто, у меня древнее видеоядро, и оно несовместимо с новой версией джавы)
Пж, помогите, вот железо:
Процессор: Intel Core 2 Duo E8400
Видеоядро (НЕ ВИДЕОКАРТА, А ВИДЕОЯДРО): Intel Q43/Q45 Express Chipset
ОЗУ: 4GB
ОС: Windows 10 x64
Разрядность: 64 бит
Заранее прошу не писать такие недосоветы, вроде:
1. Обнови драйвера
2. Переустанови винду
3. Похорони мамку
Caman86
Звание: V.I.P на хуторе
Мне нужен вот это файлик:
Пока могу предположить, что ты поставил 10-11 java, вместо 8, и из-за этого крашит. Но это всё, что я могу сказать на данный момент.
Azgolord123
Здравствуйте,делаю сборку Майнкрафт,после того как поставил placeableitems игра крашит,и выдает такую ошибку
WARNING: coremods are present:
ForgelinPlugin (Forgelin_1.8.4.jar)
TransformLoader (DynamicSurroundings-1.12.2-3.6.1.0.jar)
AstralCore (astralsorcery_1.12.2_1.10.27.jar)
HCASM (hammerlib-1.12.2-2.0.6.26.jar)
PhosphorFMLLoadingPlugin (phosphor-1.12.2-0.2.6build50-universal.jar)
CTMCorePlugin (CTM-MC1.12.2-1.0.2.31.jar)
SSLoadingPlugin (sereneseasons-1.12.2-1.2.18-universal.jar)
TheBetweenlandsLoadingPlugin (TheBetweenlands-3.7.2-core.jar)
llibrary (llibrary-core-1.0.11-1.12.2.jar)
LoadingPlugin (chunkanimator-mc1.12-1.2.jar)
AppleCore (applecore-mc1.12.2-3.4.0.jar)
ratscore (rats-3.2.14-1.12.2.jar)
ParagliderLoadingPlugin (Paragliders-Mod-1.12.2.jar)
PassableLeavesCore (PassableLeavesCore-1.12.2-1.0.0.jar)
CreativePatchingLoader (CreativeCore_v1.10.47_mc1.12.2.jar)
MovingWorldCore (movingworld-1.12-6.342-full.jar)
Contact their authors BEFORE contacting forge
// There are four lights!
Time: 3/8/21 6:49 PM
Description: Initializing game
Дюк, вынеси мусор! — Часть 3
Сегодня мы продолжаем цикл статей о сборщиках мусора, поставляемых с виртуальной машиной Oracle Java HotSpot VM. Мы уже изучили немного теории и рассмотрели, каким образом с кучей расправляются два базовых сборщика — Serial GC и Parallel GC. А в этой статье речь пойдет о сборщиках CMS GC и G1 GC, первостепенной задачей которых является минимизация пауз при наведении порядка в памяти приложений, оперирующих средними и большими объемами данных, то есть по большей части в памяти серверных приложений.
Два этих сборщика объединяют общим названием «mostly concurrent collectors», то есть «по большей части конкурентные сборщики». Это связано с тем, что часть своей работы они выполняют параллельно с основными потоками приложения, то есть в какие-то моменты конкурируют с ними за ресурсы процессора. Конечно, это не проходит бесследно, и в итоге они разменивают улучшение в части пауз на ухудшение в части пропускной способности. Хотя делают это по-разному. Давайте посмотрим, как.
CMS GC
Использование CMS GC включается опцией -XX:+UseConcMarkSweepGC.
Принципы работы
Мы уже встречали слова Mark и Sweep при рассмотрении последовательного и параллельного сборщиков (если вы не встречали, то сейчас как раз самое время это сделать). Они обозначали два шага в процессе сборки мусора в старшем поколении: пометку выживших объектов и удаление мертвых объектов. Сборщик CMS получил свое название благодаря тому, что выполняет указанные шаги параллельно с работой основной программы.
При этом CMS GC использует ту же самую организацию памяти, что и уже рассмотренные Serial / Parallel GC: регионы Eden + Survivor 0 + Survivor 1 + Tenured и такие же принципы малой сборки мусора. Отличия начинаются только тогда, когда дело доходит до полной сборки. В случае CMS ее называют старшей (major) сборкой, а не полной, так как она не затрагивает объекты младшего поколения. В результате, малая и старшая сборки здесь всегда разделены. Одним из побочных эффектов такого разделения является то, что все объекты младшего поколения (даже потенциально мертвые) могут играть роль корней при определении статуса объектов в старшем поколении.
Важным отличием сборщика CMS от рассмотренных ранее является также то, что он не дожидается заполнения Tenured для того, чтобы начать старшую сборку. Вместо этого он трудится в фоновом режиме постоянно, пытаясь поддерживать Tenured в компактном состоянии.
Давайте рассмотрим, что из себя представляет старшая сборка мусора при использовании CMS GC.
Начинается она с остановки основных потоков приложения и пометки всех объектов, напрямую доступных из корней. После этого приложение возобновляет свою работу, а сборщик параллельно с ним производит поиск всех живых объектов, доступных по ссылкам из тех самых помеченных корневых объектов (эту часть он делает в одном или в нескольких потоках).
Естественно, за время такого поиска ситуация в куче может поменяться, и не вся информация, собранная во время поиска живых объектов, оказывается актуальной. Поэтому сборщик еще раз приостанавливает работу приложения и просматривает кучу для поиска живых объектов, ускользнувших от него за время первого прохода. При этом допускается, что в живые будут записаны объекты, которые на время окончания составления списка таковыми уже не являются. Эти объекты называются плавающим мусором (floating garbage), они будут удалены в процессе следующей сборки.
После того, как живые объекты помечены, работа основных потоков приложения возобновляется, а сборщик производит очистку памяти от мертвых объектов в нескольких параллельных потоках. При этом следует иметь в виду, что после очистки не производится упаковка объектов в старшем поколении, так как делать это при работающем приложении весьма затруднительно.
Сборщик CMS достаточно интеллектуальный. Например, он старается разносить во времени малые и старшие сборки мусора, чтобы они совместно не создавали продолжительных пауз в работе приложения (дополнительные подробности об этом разнесении в комментариях). Для этого он ведет статистику по прошедшим сборкам и исходя из нее планирует последующие.
Отдельно следует рассмотреть ситуацию, когда сборщик не успевает очистить Tenured до того момента, как память полностью заканчивается. В этом случае работа приложения останавливается, и вся сборка производится в последовательном режиме. Такая ситуация называется сбоем конкурентного режима (concurrent mode failure). Сборщик сообщает нам об этих сбоях при включенных опциях -verbose:gc или -Xloggc:filename.
У CMS есть один интересный режим работы, называемый Incremental Mode, или i-cms, который заставляет его временно останавливаться при выполнении работ параллельно с основным приложением, чтобы на короткие периоды высвобождать ресурсы процессора (что-то вроде АБС у автомобиля). Это может быть полезным на машинах с малым количеством ядер. Но данный режим уже помечен как не рекомендуемый к применению и может быть отключен в будущих релизах, поэтому подробно его разбирать не будем.
Ситуации STW
Настройка
Так как подходы к организации памяти у CMS аналогичны используемым в Serial / Parallel GC, для него применимы те же опции определения размеров регионов кучи, а также опции автоматической подстройки под требуемые параметры производительности.
Достоинства и недостатки
Достоинством данного сборщика по сравнению с рассмотренными ранее Serial / Parallel GC является его ориентированность на минимизацию времен простоя, что является критическим фактором для многих приложений. Но для выполнения этой задачи приходится жертвовать ресурсами процессора и зачастую общей пропускной способностью.
Вспомним еще, что данный сборщик не уплотняет объекты в старшем поколении, что приводит к фрагментации Tenured. Этот факт в совокупности с наличием плавающего мусора приводит к необходимости выделять приложению (конкретно — старшему поколению) больше памяти, чем потребовалось бы для других сборщиков (Oracle советует на 20% больше).
Ну и долгие паузы при потенциально возможных сбоях конкурентного режима могут стать неприятным сюрпризом. Хотя они не частые, и при наличии достаточного объема памяти CMS’у удается их полностью избегать.
Тем не менее, такой сборщик может подойти приложениям, использующим большой объем долгоживущих данных. В этом случае некоторые его недостатки нивелируются. Но в любом случае, не стоит принимать решение о его использовании пока вы не познакомились с еще одним сборщиком в обойме Java HotSpot VM.
G1 GC
Вот мы и добрались до последнего и наверняка самого интересного для многих сборщика мусора — G1 (что является сокращением от Garbage First). Интересен он прежде всего тем, что не является явным продолжением линейки Serial / Parallel / CMS, добавляющим параллельность еще в какую-нибудь фазу сборки мусора, а использует уже существенно отличающийся подход к задаче очистки памяти.
G1 — самый молодой в составе сборщиков мусора виртуальной машины HotSpot. Он изначально позиционировался как сборщик для приложений с большими кучами (от 4 ГБ и выше), для которых важно сохранять время отклика небольшим и предсказуемым, пусть даже за счет уменьшения пропускной способности. На этом поле он конкурировал с CMS GC, хотя изначально и не так успешно, как хотелось бы. Но постепенно он исправлялся, улучшался, стабилизировался и, наконец, достиг такого уровня, что Oracle говорит о нем как о долгосрочной замене CMS, а в Open JDK даже серьезно рассматривают его на роль сборщика по умолчанию для серверных конфигураций в 9-й версии.
Это все явно стоит того, чтобы разобраться с его устройством. Не будем же откладывать.
Принципы работы
Первое, что бросается в глаза при рассмотрении G1 — это изменение подхода к организации кучи. Здесь память разбивается на множество регионов одинакового размера. Размер этих регионов зависит от общего размера кучи и по умолчанию выбирается так, чтобы их было не больше 2048, обычно получается от 1 до 32 МБ. Исключение составляют только так называемые громадные (humongous) регионы, которые создаются объединением обычных регионов для размещения очень больших объектов.
Разделение регионов на Eden, Survivor и Tenured в данном случае логическое, регионы одного поколения не обязаны идти подряд и даже могут менять свою принадлежность к тому или иному поколению. Пример разделения кучи на регионы может выглядеть следующим образом (количество регионов сильно приуменьшено):
Малые сборки выполняются периодически для очистки младшего поколения и переноса объектов в регионы Survivor, либо их повышения до старшего поколения с переносом в Tenured. Над переносом объектов трудятся несколько потоков, и на время этого процесса работа основного приложения останавливается. Это уже знакомый нам подход из рассмотренных ранее сборщиков, но отличие состоит в том, что очистка выполняется не на всем поколении, а только на части регионов, которые сборщик сможет очистить не превышая желаемого времени. При этом он выбирает для очистки те регионы, в которых, по его мнению, скопилось наибольшее количество мусора и очистка которых принесет наибольший результат. Отсюда как раз название Garbage First — мусор в первую очередь.
После окончания цикла пометки G1 переключается на выполнение смешанных сборок. Это значит, что при каждой сборке к набору регионов младшего поколения, подлежащих очистке, добавляется некоторое количество регионов старшего поколения. Количество таких сборок и количество очищаемых регионов старшего поколения выбирается исходя из имеющейся у сборщика статистики о предыдущих сборках таким образом, чтобы не выходить за требуемое время сборки. Как только сборщик очистил достаточно памяти, он переключается обратно в режим малых сборок.
Очередной цикл пометки и, как следствие, очередные смешанные сборки будут запущены тогда, когда заполненность кучи превысит определенный порог.
Смешанная сборка мусора в приведенном выше примере кучи может пройти вот так:
Может оказаться так, что в процессе очистки памяти в куче не остается свободных регионов, в которые можно было бы копировать выжившие объекты. Это приводит к возникновению ситуации allocation (evacuation) failure, подобие которой мы видели в CMS. В таком случае сборщик выполняет полную сборку мусора по всей куче при остановленных основных потоках приложения.
Опираясь на уже упомянутую статистику о предыдущих сборках, G1 может менять количество регионов, закрепленных за определенным поколением, для оптимизации будущих сборок.
Гиганты
В продолжении данного цикла статей мы посмотрим, как с этим можно бороться.
Ситуации STW
Настройка
Опции и задают количество потоков, которые будут использоваться для сборки мусора и для выполнения цикла пометок соответственно.
Если же вы решите залезть в дебри настроек G1 по-глубже, то можете включить дополнительные функции опциями и и поиграть с экспериментальными настройками.
Достоинства и недостатки
В целом считается, что сборщик G1 более аккуратно предсказывает размеры пауз, чем CMS, и лучше распределяет сборки во времени, чтобы не допустить длительных остановок приложения, особенно при больших размерах кучи. При этом он лишен и некоторых других недостатков CMS, например, он не фрагментирует память.
Расплатой за достоинства G1 являются ресурсы процессора, которые он использует для выполнения достаточно большой части своей работы параллельно с основной программой. В результате страдает пропускная способность приложения. Целевым значением пропускной способности по умолчанию для G1 является 90%. Для Parallel GC, например, это значение равно 99%. Это, конечно, не значит, что пропускная способность с G1 всегда будет почти на 10% меньше, но данную особенность следует всегда иметь в виду.
Вот мы и разобрали алгоритмы работы всех четырех сборщиков мусора в виртуальной машине HotSpot. В следующей статье попробуем разобраться, каким образом эти знания можно применять для оптимизации работы приложений.