Skip to content

Commit a6da8c3

Browse files
zero2hjzero2hj
committed
Update
1 parent e1e44b8 commit a6da8c3

11 files changed

Lines changed: 411 additions & 4 deletions

File tree

‎.gitignore‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
public/

‎.gitmodules‎

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
11
[submodule "themes/hugo-lithium"]
22
path = themes/hugo-lithium
3-
url = git@github.com:draveness/hugo-lithium.git
3+
url = https://github.com/draveness/hugo-lithium.git
4+
branch = master
5+
[submodule "themes/simple"]
6+
path = themes/simple
7+
url = https://github.com/barklan/hugo-dead-simple.git

‎config.toml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,14 @@ ignoreFiles = ["\\.Rmd$", "\\.Rmarkdown$", "_files$", "_cache$"]
1919
name = "demo"
2020
url = "/pl/"
2121

22+
[[menu.main]]
23+
name = "Categories"
24+
url = "/categories/"
25+
26+
[[menu.main]]
27+
name = "Tags"
28+
url = "/tags/"
29+
2230
[params]
2331
description = "A website built through Hugo and blogdown."
2432

‎content/posts/Java_gc.md‎

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
---
2+
title: "Java_gc"
3+
date: 2025-02-20T00:01:43+08:00
4+
draft: false
5+
---
6+
7+
# measure
8+
throughput indicate percentage of time used in application against gc. the more frequent gc work, the more resource it take away from application which affect throughput even if with concurrent. If reduce the frequency of gc and don't gc before garbage has accumulate to large amount, it will decrease total cpu and footprint cost on gc but may increase the paused time in this big gc work round.
9+
10+
response time, as what said above, gc more frequent with short pause time, with small effect to user interactive application.
11+
12+
>
13+
14+
# design
15+
most of time, we don't want the ultimate, long time paused gc and was supposed to increase gc oppotunity but not influence throughput that much.
16+
1. Generation hypothesis. most objects live a short time, objects age get to more long, the less oppotunity they will be collected. it increase times to gc young objects but decrease times to gc old objects to achieve the balance.
17+
2. concurrent with application at some phase can reduce pause time to gain low latency.
18+
19+
20+
# key
21+
## how to check live objects
22+
23+
### Reachability analysis.
24+
1. list gc root
25+
2. mark phase(track the reference tree from gc root)
26+
consisder reference as alive only if there is the path from gc root to the object. gc roots are stack variable, class static variable, string table, JNI, class object.
27+
finding gc roots phase must stop the world,
28+
and optimizition direction was about to reduce the range to find gc root, e.g. minor gc only need to find reference in eden space(also inter-generation reference)
29+
30+
31+
mark phase should also start from the consistent snapshot, otherwise the reachability of the reference would change, from live to dead, even worse garbage become referenced by other live ref.
32+
33+
as heap grows, serialize mark phase seek a way to become concurrent, arise the requisite to solve reference relation change through phase.
34+
consisder these scenes: 1. object was scanned but origin reference relation was break. It would become a float garbage can't be collected until next gc round 2. object was not scanned yet and change to be referenced by an already scanned ref, so it won't be scanned in this initial mark round.
35+
36+
java collection use tri-color marking algorithm in marking phase and to solve above problem which called "lost-object-problem" introduce two other solutions: incremental update and snatshot at the begining(SATB).each solution break one of two condition that must meet if the lost object happens: ·赋值器插入了一条或多条从黑色对象到白色对象的新引用； ·赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。
37+
38+
### SATB
39+
- write barrier to detect b.c = null, speculate c is alive,
40+
- preserve the b->c relation at marking start
41+
- process c in remarking phase?
42+
- can not handle floating garbage(new garbage)
43+
44+
### multiple marking
45+
take CMS as an example: initial marking phase list gc roots and gc directly reached object. concurrent marking means gc threads work concurrent with application threads. remarking phase handle incremental update during concurent marking phase.
46+
47+
48+
## how to evacuate space
49+
50+
there are 3 methods: sweep, copy, compact.
51+
sweep was not efficient when more objs were short-live and also will cause memory fragement.
52+
copy live objects to one place, and sweep last place. not fit into old generation because of high percentage of live objects.
53+
compact was designed for old gen to solve 分配担保.
54+
55+
consisder 3 method, copy & move was not efficient at gc time, but sweep need to do more work(空闲分配链表) when allocate memory to handle memory fragement. And because memory alloc and access are more frequent we can conclude sweep method has low throughput then copy method.
56+
57+
## phases & STW
58+
59+
different algorithm and gc implementations pause at stw time in different phase. there are also pause free alogrithm that do not require pause.
60+
61+
commons phases
62+
63+
initial mark
64+
remark
65+
evacuate
66+
re-allocate
67+
68+
69+
# implementation(different collectors)
70+
earlier to latest. for different generation. for throughput or low lattency or balance.
71+
72+
## serialize
73+
- young (copy), old (sweep)
74+
-
75+
## parnew
76+
- young (copy)
77+
- parallel
78+
- used with cms for old gc
79+
## parallel scavenge
80+
- young (copy)
81+
- compare parnew friendly to cpu resource sensitive application
82+
- not compatible with cms. instead parallel scavenge + parallel old
83+
84+
detail:
85+
`-XX: GCTimeRatio`, lower ratio higher throughput
86+
`-XX: MaxGCPauseTime`, higher throughput means more space to collect and higher pause time.
87+
`-XX: UseAdaptiveSizePolicy`, GC Ergonomics auto-tune generation sizes by specify preferer
88+
89+
see more detail [here](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html)
90+
91+
## cms
92+
- old (sweep)
93+
- phases: initial mark, concurrent mark, re-mark, concurrent sweep
94+
- cons: cpu sensitive, contention resource with application. cannot collect floating garbage may encounter concurrent mode failure(no more free space to allocate for application thread) and will go back to full gc. sweep cause memory fragmentation.
95+
96+
## g1
97+
- region based. collection set instead of whole generation, so called mixed gc.
98+
- region size 1-32MB
99+
- inter-region reference, remember set and card table
100+
101+
### remember set & card table
102+
for the purpose to remember which old region obj has pointers to current region, jvm add write barrier to pointer assigment statement.
103+
for memory efficiency, instead of recording each object, card table record only high level of object address, which is bucket the obj reside in.
104+
each bit in card table indicate the bucket at the index is dirty.
105+
106+
remember set is k-v structure, k to find region, v to find card
107+
108+
### phases
109+
110+
### tuning
111+
112+
113+
114+
## shenandoah
115+
116+
## zgc
117+
118+
generational logic heap memory was implemented in all kinds of collectors and different generation may use different algorithm as discussed before, old generation mark compact, young gen mark copy.
119+
120+
collectors are for specific generation and require other collector to work together.
121+
122+
since cms there
123+
124+
125+
g1 remember set consume much memory
126+
127+
g1 2nd phase need build rset after checkout candidate set to reclaim , then move to space reclaimation phase collect and reclaiming space in old region from collection set candidate
128+
129+
rset maintain
130+
131+
132+
133+
card table each bit says some portion is dirty-has pointers to other generation.
134+
135+
Per region has remember set track these card tables related to its region. When scan the region it will also need to scan the card table region too.
136+
137+
Card table structure maintains?
138+
139+
As remember set will consume much memory if it has many track information so young gen was divided into small regions
140+
141+
# ref
142+
1. 深入理解Java虚拟机
143+
2. G1 Garbage Collector Details and Tuning by Simone Bordet(https://www.youtube.com/watch?v=Gee7QfoY8ys)
144+
145+
other gc related materials:
146+
Shenandoah GC Part I ： The Garbage Collector That Could
147+
https://gchandbook.org/contents.html

‎content/posts/Java_method_execution.md‎

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
---
2+
title: "Java 方法执行"
3+
date: 2024-06-09T20:44:02+08:00
4+
draft: false
5+
---
6+
7+
- 从源码到cpu执行的过程梳理
8+
- common method execution scenarios such as main method, constructor, static method, polymorphism, reflection, lambda expression
9+
- beyond java
10+
11+
# how source code execute to cpu
12+
13+
JVM load class file and interpret/execute the bytecode.
14+
15+
class file contains byte sequence, which is platform neutral.
16+
- Java source code was compiled to platform neutral byte code, wellknowed as class file. java class file is with strict format, define every thing of java class.
17+
18+
- class loading is the process of loading class file into java virtual machine at runtime, the method area, basicly.
19+
20+
- main method is the entry point of java application, jvm then continue to load and execute from that.
21+
22+
23+
24+
# method invocation scenarios
25+
26+
main方法
27+
28+
new 关键字构造对象执行时分为两个指令, new 和 invokespecial <init>
29+
30+
>检查 new 指令参数指向的符号引用对应类是否被加载
31+
分配内存，内存大小在类加载时确定。
32+
Java内存分配线程安全
33+
初始化内存，设置字段#零值
34+
对象头设置
35+
new 关键字对应第二条指令 `invokespecial <init>` [[<init>]]。Java 类编译时生成`<init>`收敛方法，依次包含对父类无参构造器，子类无参构造器，字段初始化等
36+
37+
invoke方法调用指令的一般执行过程
38+
39+
> invoke指令后面的参数(非方法参数) 方法的符号引用，指向常量池中方法名称和描述符常量。这些符号引用是在编译时由编译器根据接收者的静态类型和参数的静态类型，确定方法版本，生成确定的invoke指令，即invoke参数为符号引用。
40+
> 一些指令的符号引用在类加载解析阶段或第一次使用时变为直接引用，直接指向方法的内存结构。
41+
> 对于invokevirtual，要在运行时判断接收者的实际类型进行动态分派。
42+
43+
对于 private 方法, 构造器方法, super方法, final方法, static 方法这几类的符号引用均可以在类加载即转换为唯一的直接引用。
44+
其中private, 构造器, super方法调用对应的字节码指令为invokespecial。
45+
static invokestatic
46+
final方法的字节码invokevirtual
47+
48+
Java中成员方法默认为虚方法(与c++虚函数类似)，虚方法调用机制为动态分派，运行时根据方法接收者的实际类型动态判断符号引用的指向方法的唯一版本。
49+
50+
与动态分派(dynamic dispatch)对应静态绑定(或静态解析、)，
51+
52+
53+
反射方式进行方法调用，同普通方法调用，将参数传递给方法区的方法对象，不同的地方在于普通方法调用依赖编译器必须知道参数的静态类型（not实际类型）静态解析或动态分派完成方法分派，而反射提供类似动态语言的特性，只要target有该Method方法即可完成调用，否则抛出NoSuchMethodException。
54+
反射实现方式有两种，native code 和 bytecode-based（动态字节码）。
55+
从java 18开始，反射的底层实现变为MethodHandle，提供更现代化的反射实现。
56+
57+
lambda expression
58+
59+
60+
61+
62+
63+
- javap -verbose 查看class文件字节码内容
64+
- [] method reflection metadata
65+
- https://stackoverflow.com/questions/5698614/java-final-methods-vs-c-nonvirtual-functions
66+
- [反射性能开销原理及优化](https://github.com/xfhy/Android-Notes/blob/master/Blogs/Java/%E5%9F%BA%E7%A1%80/%E5%8F%8D%E5%B0%84%E6%80%A7%E8%83%BD%E5%BC%80%E9%94%80%E5%8E%9F%E7%90%86%E5%8F%8A%E4%BC%98%E5%8C%96.md)
67+
68+
69+
70+
a class byte sequence describe the original class structure, using well defined differrent data types for different parts of class, such as class hirachechy, field, method signature and the method code, etc.
71+
72+
method code is compiled to byte code. method invoke code was compiled to versatile byte code instruction, the instruction may follow the symbolic reference, which is used for jvm engine to find the target method.
73+
74+
when jvm interprete to execute the byte code, different
75+
76+
- Java source code was compiled to platform neutral byte code, wellknowed as class file. java class file is with strict format, define every thing of java class.
77+
78+
- class loading is the process of loading class file into java virtual machine at runtime, the method area, basicly.
79+
80+
- main method is the entry point of java application, jvm then continue to load and execute from that.
81+

‎content/posts/blog_setup.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,8 @@
22
title: "Blog_setup"
33
date: 2022-10-02T21:36:07+08:00
44
draft: false
5+
categories:
6+
- "reference"
57
---
68

79
# hugo quick start

‎content/posts/concurrency.md‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
---
2+
title: "Concurrency"
3+
date: 2025-03-04T21:09:21+08:00
4+
draft: true
5+
---
6+
7+
为什么出发
8+
9+
程序抽象进程，由os调度执行。所谓调度是由于必须让许多进程同时在有限的cpu上执行即cpu virtialization。操作系统的调度机制通过中断实现的（trap vs interrupt）。
10+
11+
中断发生后，os调度决定是否切换进程，是则进行context switch, 由硬件支持，os内核模式完成。最终用户模式执行新进程。
12+
13+
CPU存在硬件缓存（本地副本），利用时间和空间的 cache locality 以提升程序性能。
14+
多cpu调度时，每个cpu缓存独立，相当于同一块内存在时空上的不同副本，这种分布式的数据读写一定存在一致性问题，如读旧值、丢失更新，解法通常包括
15+
16+
硬件提供了机制，检测内存数据更新使本地副本失效。这只解决了一部分问题，即内存->缓存刷新，缓存之间仍具有不可见性。
17+
18+
线程是程序调度的基本单位（或者说是OS需要负责调度的最小单位），创建线程使进程具有利用多cpu核心的能力，共享数据以高效地在线程间互相通信。
19+
线程安全问题依然在于不可控的调度，如这个广泛引用的例子：a=a+1，两个线程并发对同一个值累加1万次，结果大概率不是20000。由于这个语句不是原子操作（查看其汇编码可知），随时可能被中断，线程切换时保存或恢复各自专用寄存器的值，切换回时由于寄存器中的源值内存值可能已经变更。
20+
21+
Concurrency 不止发生在多核系统，可以在单核运行多线程程序，这种程序亦会发生待解决的同步问题，因为中断 上下文切换依然存在。
22+
23+
Dijkstra 命名了上述的现象为 race condition, 涉及的代码段为临界区。只要程序依赖不可控的顺序，就会发生race。
24+
25+
我们希望避免临界区的race, 或者关闭中断，或者使临界区为原子操作。
26+
27+
编程语言中常见锁结构即是第二个思路的实现。锁通常由硬件以及软件(OS)提供支持。如由硬件提供的原子指令可用于实现自旋锁。由于自旋性能问题，OS实现park和unpark结合自旋实现高性能锁。
28+
29+
注：锁隐含了memory barriers 以实现读和写的可见性。
30+
31+
除了原子性问题，并发程序还会遇到顺序问题，以及死锁。
32+
33+
Java memory model
34+
35+
因为cache 使共享变量具有多个副本，而reordering进一步扰乱了这种可见性,多线程程序中需要明确对变量的更新是否能被其他线程读到。因此memory model 定义了必要且充分的visibility条件，guarantee。jmm提供了跨不同架构的同步语义。
36+
37+
mm包含了一些机制和内置约束.
38+
39+
happen-before 定义了这些基础顺序约束
40+
1 program order, 一切顺序的基础。
41+
2 lock unlock order
42+
3 thread start order
43+
4 volatile order
44+
5 join order
45+
46+
47+
互斥（锁）只是同步的一方面，还需要解决内存可见性，进出临界区隐含是缓存和内存一致。同时由于指令重排序多线程时违反程序期望的可见性顺序造成问题，如常见的new 对象构造，new关键字编译为三条基础指令，重排序导致线程在对象未初始化即被访问到。
48+
49+
JMM 提供跨硬件和OS的一致性语义，描述了多线程读写共享变量的行为，确保他们在所有架构上正确。
50+
51+
all is about happen-before定义了JMM保证的
52+
53+
54+
todo
55+
56+
kernal and user space
57+
58+
进程切换 vs 线程切换 vs 协程切换
59+
60+
切换状态：寄存器和缓存
61+
62+
trap and interrupt
63+
64+
- 操作系统导论 雷姆兹•H.阿帕希杜塞尔和安德莉亚•C.阿帕希杜塞尔著
65+
- http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

‎content/posts/demo/_index.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,8 +9,8 @@ non_ls_tpl: true
99

1010
# h1 in content
1111

12-
## h2
12+
<!-- ## h2
1313
- [Java]({{< ref "Java" >}})
1414
1515
## h2
16-
- [Go]({{< ref "go" >}})
16+
- [Go]({{< ref "go" >}}) -->

0 commit comments

Comments
 (0)