Custom Class Loading in Dalvik
http://android-developers.blogspot.kr/2011/07/custom-class-loading-in-dalvik.html
=> 위 내용에의 요약
1. Dalvik은 custom class를 로딩하는 것을 지원한다.
보통은 이렇게 클래스를 로딩하는 것이 필요없지만 필요한 경우가 있다.
- 크기가 큰 앱은 dex가 최대로 지원하는 64k method reference이상을 포함할 수 있다. 이 경우는 프로그램을 두개의 dex로 나누어서 피해갈 수 있다.
- 프레임워크의 형태가 런타임에 동적으로 로딩하는 형태일 수 있다.
2014년 2월 17일 월요일
자바 메모리 모델에 대하여
Java Memory Model Under The Hood
http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html
-> 위의 내용에 대한 간단 요약
1. 하드웨어 레벨에서의 자바 메모리 모델에 대한 설명
메인 메모리를 직접 사용하는 것은 매우 느리므로 캐시를 사용한다. 캐시는 하나의 프로세서에서는 문제없이 잘 동작하지만 프로세서가 여러개(실행이 동시에 여러군데서 되는 경우)인 경우 문제가 매우 복잡해진다(한쪽에서 캐시한 것을 다른 쪽에서 값을 바꾸어 버린다던지 하는 경우가 있을 수 있다.).
cach에 대한 설명: http://arstechnica.com/gadgets/2002/07/caching/2/
- Cache Coherency Protocols
MESI에서 모든 캐시는 아래의 상태를 가진다.
Invalid: 캐시가 메모리의 값을 가지고 있지 않다.
Exclusive: 값이 캐시에 있지만 변경되지 않았다.
Modified: 값이 변경되었지만 메인 메모리에 다시 쓰여지지 않았다.
Shared: 하나 이상의 프로세서가 같은 메모리의 값을 캐시에 가지고 있다.
Shared 상태에 있는 값을 바꾸고 싶으면 Invalidate 메시지를 다른 프로세서에 보내고 ack를 받으면 값을 변경한다. 이것은 시간이 매우 많이 걸리는 문제가 있다. -> Store Buffer를 사용해서 시간 낭비문제를 해결한다: 값을 버퍼에 넣어두고 모든 invalidate 메시지가 오면 값을 commit한다.
- Store Buffer의 두가지 문제점
1. store buffer에 있는 값이 완전히 commit 되지 않았는데 이를 읽어가는 문제가 있을 수 있다: Store Forwarding
2. 값이 버퍼를 떠나는 순서가 보장되지 않는다.
Invalidate Queues: invalidation을 처리하기 위해 도입
- Invalidate 요청이 들어오면 Invalidate Acknowledge 메시지는 바로 보내진다.
- Invalidate는 바로 적용되는 것이 아니라 special queue에 있다가 편리한 때 실행된다.
- 프로세서는 Invalidate를 모두 처리하고 나서야 캐시에 있는 메시지를 처리한다.
* Store Memory Barrier
store buffer에 있는 모든 것들을 다 적용한 후 이후에 오는 것들을 적용한다.
* Load Memory Barrier
invalidate queue에 있는 모든 invalidate들을 적용한 후
2. OpenJDK 소스 레벨에서의 자바 메모리 모델에 대한 설명
http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html
-> 위의 내용에 대한 간단 요약
1. 하드웨어 레벨에서의 자바 메모리 모델에 대한 설명
메인 메모리를 직접 사용하는 것은 매우 느리므로 캐시를 사용한다. 캐시는 하나의 프로세서에서는 문제없이 잘 동작하지만 프로세서가 여러개(실행이 동시에 여러군데서 되는 경우)인 경우 문제가 매우 복잡해진다(한쪽에서 캐시한 것을 다른 쪽에서 값을 바꾸어 버린다던지 하는 경우가 있을 수 있다.).
cach에 대한 설명: http://arstechnica.com/gadgets/2002/07/caching/2/
- Cache Coherency Protocols
MESI에서 모든 캐시는 아래의 상태를 가진다.
Invalid: 캐시가 메모리의 값을 가지고 있지 않다.
Exclusive: 값이 캐시에 있지만 변경되지 않았다.
Modified: 값이 변경되었지만 메인 메모리에 다시 쓰여지지 않았다.
Shared: 하나 이상의 프로세서가 같은 메모리의 값을 캐시에 가지고 있다.
Shared 상태에 있는 값을 바꾸고 싶으면 Invalidate 메시지를 다른 프로세서에 보내고 ack를 받으면 값을 변경한다. 이것은 시간이 매우 많이 걸리는 문제가 있다. -> Store Buffer를 사용해서 시간 낭비문제를 해결한다: 값을 버퍼에 넣어두고 모든 invalidate 메시지가 오면 값을 commit한다.
- Store Buffer의 두가지 문제점
1. store buffer에 있는 값이 완전히 commit 되지 않았는데 이를 읽어가는 문제가 있을 수 있다: Store Forwarding
2. 값이 버퍼를 떠나는 순서가 보장되지 않는다.
Invalidate Queues: invalidation을 처리하기 위해 도입
- Invalidate 요청이 들어오면 Invalidate Acknowledge 메시지는 바로 보내진다.
- Invalidate는 바로 적용되는 것이 아니라 special queue에 있다가 편리한 때 실행된다.
- 프로세서는 Invalidate를 모두 처리하고 나서야 캐시에 있는 메시지를 처리한다.
* Store Memory Barrier
store buffer에 있는 모든 것들을 다 적용한 후 이후에 오는 것들을 적용한다.
* Load Memory Barrier
invalidate queue에 있는 모든 invalidate들을 적용한 후
2. OpenJDK 소스 레벨에서의 자바 메모리 모델에 대한 설명
디자이너들이 많이 가는 사이트 모음
Where designers go to find photos and graphics
http://www.sitebuilderreport.com/blog/where-the-best-designers-go-to-find-photos-and-graphics
저같은 디자인에 문외한인 사람들이 가져다 쓰면 좋을 것들이 많이 있네요. 저작권에 문제 없는 이런 것들 좋아요~
http://www.sitebuilderreport.com/blog/where-the-best-designers-go-to-find-photos-and-graphics
저같은 디자인에 문외한인 사람들이 가져다 쓰면 좋을 것들이 많이 있네요. 저작권에 문제 없는 이런 것들 좋아요~
2014년 2월 13일 목요일
비트코인 프로토콜을 통한 비트코인 설명
Bitcoins the hard way: Using the raw Bitcoin protocol
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
-> 위의 내용에 대한 요약
* 비트코인 address
1. random 256-bit private key를 생성한다. 나중에 transaction을 sign하는데 사용된다.
2. private key를 가지고 Elliptic Curve DSA 알고리즘을 사용해서 512-bit public key를 생성한다. 나중에 transaction에의 signature를 확인하는데 사용된다. public key의 앞에 04를 붙인다.(bitcoinj에서 bouncy castle을 사용해서 public key를 만드는데 코드를 보면 private key로부터 public key 생성시 04가 붙어서 나온다. bouncy castle는 왜 04를 붙인 public key를 주는걸까? 자세한 내용 확인 필요)
3. public key를 SHA-256과 RIPEM hash 알고리즘을 사용해서 160bit로 만든다.
4. 160bit로 만든 hash 값을 Base58Check로 인코딩한다. 이것이 사용자들이 서로 교환하는 비트코인 address이다.
5. private key를 로컬에 저장하는데 Wallet Interchange Format으로 저장한다. WIF는 단순히 Base58Check 인코딩이다.
* Transaction
1.비트코인을 이 주소에서 저 주소로 옮기는 것
2. input과 output으로 이루어진다.
3. 이전 transaction의 output으로 부터 비트코인을 가져와서 input으로 하고 보내고자 하는 쪽을 output으로 한다.
4. 모든 input은 다 사용되어야 한다. 따라서, 일부분만 쓰고자 하면 남는 부분은 자기 자신에게 다시 보내는 형태로 사용한다.
5. 사용료(fee)가 있다. 사용하고 남는 값이 모두 fee가 된다. 보통 값이 그리 크지는 않다.
* Transaction을 sign하기
1. transaction의 내용을 private key로 hash한 다음에 sign한다.
2. public key가 transaction에 포함되는데 이 key가 맞는 지는 이전의 transaction에서의 address를 봄으로서 파악할 수 있다.
3. signing한 것을 public key로 verify할 수 있다.
* peer 찾기
1. 하나의 peer와 연결되면 이 peer와 서로 알고 있는 다른 peer들의 주소를 교환한다.
2. 그렇다면 가장 처음의 peer는 어떻게? - 몇개의 신뢰할만한 peer가 이미 네트워크 상에 존재하도록 만든다: DNS에 등록해 놓거나 프로그램에 미리 입력해 놓기.
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
-> 위의 내용에 대한 요약
* 비트코인 address
1. random 256-bit private key를 생성한다. 나중에 transaction을 sign하는데 사용된다.
2. private key를 가지고 Elliptic Curve DSA 알고리즘을 사용해서 512-bit public key를 생성한다. 나중에 transaction에의 signature를 확인하는데 사용된다. public key의 앞에 04를 붙인다.(bitcoinj에서 bouncy castle을 사용해서 public key를 만드는데 코드를 보면 private key로부터 public key 생성시 04가 붙어서 나온다. bouncy castle는 왜 04를 붙인 public key를 주는걸까? 자세한 내용 확인 필요)
3. public key를 SHA-256과 RIPEM hash 알고리즘을 사용해서 160bit로 만든다.
4. 160bit로 만든 hash 값을 Base58Check로 인코딩한다. 이것이 사용자들이 서로 교환하는 비트코인 address이다.
5. private key를 로컬에 저장하는데 Wallet Interchange Format으로 저장한다. WIF는 단순히 Base58Check 인코딩이다.
* Transaction
1.비트코인을 이 주소에서 저 주소로 옮기는 것
2. input과 output으로 이루어진다.
3. 이전 transaction의 output으로 부터 비트코인을 가져와서 input으로 하고 보내고자 하는 쪽을 output으로 한다.
4. 모든 input은 다 사용되어야 한다. 따라서, 일부분만 쓰고자 하면 남는 부분은 자기 자신에게 다시 보내는 형태로 사용한다.
5. 사용료(fee)가 있다. 사용하고 남는 값이 모두 fee가 된다. 보통 값이 그리 크지는 않다.
* Transaction을 sign하기
1. transaction의 내용을 private key로 hash한 다음에 sign한다.
2. public key가 transaction에 포함되는데 이 key가 맞는 지는 이전의 transaction에서의 address를 봄으로서 파악할 수 있다.
3. signing한 것을 public key로 verify할 수 있다.
* peer 찾기
1. 하나의 peer와 연결되면 이 peer와 서로 알고 있는 다른 peer들의 주소를 교환한다.
2. 그렇다면 가장 처음의 peer는 어떻게? - 몇개의 신뢰할만한 peer가 이미 네트워크 상에 존재하도록 만든다: DNS에 등록해 놓거나 프로그램에 미리 입력해 놓기.
2014년 2월 11일 화요일
MySql에서 많은 양의 데이터 다루기
Handling large data in MySql
http://tagide.com/blog/2012/08/how-to-handle-large-data-in-mysql/
-> 위의 내용에 대한 간단한 요약입니다.
1. MySql의 설정 조정
아래의 설정을 조정해 볼 수 있는데 아래의 값은 하나의 예이다.
key_buffer_size = 1G
sort_buffer_size = 16M
tmp_table_size = 4G
max_heap_table_size = 8G
read_buffer_size = 512K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 4G
2. 하나의 테이블에 인덱스가 있는 것을 가져오는 것은 잘 가져온다. -> 여러 테이블을 건드리는 경우 느리게 동작할 가능성이 많다.
3. explain 명령어로 MySql 명령어의 상태를 살펴 볼 수 있다.
4. 현재 느리게 동작하는 명령일지라도 인덱스를 잘 사용하면 빠르게 동작하도록 바꾸어 줄 수 있다.
5. 필요에 따라 벌크 데이터를 가져온 다음에 자바나 파이썬으로 직접 필터링이나 프로세싱을 할 수도 있다.
http://tagide.com/blog/2012/08/how-to-handle-large-data-in-mysql/
-> 위의 내용에 대한 간단한 요약입니다.
1. MySql의 설정 조정
아래의 설정을 조정해 볼 수 있는데 아래의 값은 하나의 예이다.
key_buffer_size = 1G
sort_buffer_size = 16M
tmp_table_size = 4G
max_heap_table_size = 8G
read_buffer_size = 512K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 4G
2. 하나의 테이블에 인덱스가 있는 것을 가져오는 것은 잘 가져온다. -> 여러 테이블을 건드리는 경우 느리게 동작할 가능성이 많다.
3. explain 명령어로 MySql 명령어의 상태를 살펴 볼 수 있다.
4. 현재 느리게 동작하는 명령일지라도 인덱스를 잘 사용하면 빠르게 동작하도록 바꾸어 줄 수 있다.
5. 필요에 따라 벌크 데이터를 가져온 다음에 자바나 파이썬으로 직접 필터링이나 프로세싱을 할 수도 있다.
2014년 2월 1일 토요일
Why I Dropped Dropbox and got OwnCloud
http://dorktech.com/why-i-dropped-dropbox-and-got-owncloud/
dropbox와 같은 기능을 하는 OwnCloud라는 것이 있다. 자체 서버가 있는 경우 ownCloud를 설치함으로서 dropbox에서 제공하는 기능을 자체적으로 사용할 수 있다.
dropbox와 같은 기능을 하는 OwnCloud라는 것이 있다. 자체 서버가 있는 경우 ownCloud를 설치함으로서 dropbox에서 제공하는 기능을 자체적으로 사용할 수 있다.
피드 구독하기:
글 (Atom)