땅콩의 개발일기

기존 앱부분의 코드에서는 오류가 없었는데 안드로이드로 빌드하려고 하면 뜬금 오류가 난다. 기본 생성되는 프로젝트 코드에서 문제가 생긴것 같다. 우선 app/build.gradle에서 deprecated된것으로 보이는 GradleException을 FileNotFoundException으로 바꿔준다. (사진은 오류난것처럼 보이는데 안드로이드 스튜디오로 열면 문제가 없다. ide상의 문제인듯싶다.) 그리고 아래부분을 dependencies { implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" } 아래처럼 정확한 버전으로 수정해준다. dependencies { implementation(platform("org.jetbrains...

flutter로 로컬스토리지를 사용하는 앱을 개발하며 datepicker 오픈 패키지를 커스텀해서 사용하는 과정에서 문제가 있었다. https://github.com/sivaprasadnk/SimpleMonthYearPicker GitHub - sivaprasadnk/SimpleMonthYearPicker Contribute to sivaprasadnk/SimpleMonthYearPicker development by creating an account on GitHub. github.com 기존의 CupertinoDatePicker는 일을 없애고 년과 월 옵션만 넣도록 커스텀이 안돼서 위의 오픈소스 패키지를 사용하게 되었다. 내가 구현하고자 한 기능은 datepicker를 통해 원하는 날짜를 선택하면 ..

*국민대학교 소프트웨어학부 최은미 교수님의 객체지향 분석 및 설계(OOAD) 교과목을 공부하며 정리한 내용입니다. 약 420page정도 되는 내용을 최대한 요약해서 pdf 26페이지로 정리했고, 영어로 된 자료를 한글로 최대한 쉽게 정리했습니다! 절대 완벽한 자료는 아니지만, 수업을 듣고 공부할 때 참고하신다면 훨씬 편하게 내용을 파악하실 수 있을거라고 생각합니다! 해당 포스팅에서 정리하는 내용의 목차는 아래와 같습니다. 1. OOAD introduction 2. OOAD example 3. Iterative and Evolutionary process 4. SW development process 5. UP phases Example 6. Inception Phase 7. Quality & Qualit..

stack property stack property란, 캐시사이즈가 n개일때 들어있는 내용이 캐시사이즈가 n+1개일때도(캐시사이즈를 늘렸을때도) 다 들어있는 성질이다. optimal, LRU정책의 경우 stack property를 만족하기 때문에 캐시 사이즈가 늘어나면 hit ratio가 좋아진다. 반면, FIFO의 경우 stack property를 만족하지 않기 때문에 캐시사이즈를 늘렸을 때 오히려 성능이 나빠지기도 한다. (Belady's anomaly) 각 정책별 workload optimal과 LRU는 locality에 따라 캐시를 교체하고, FIFO는 locality 고려 없이 무조건 오래된 캐시를 교체하고, random은 아무런 기준없이 랜덤하게 캐시를 교체한다. 이런 여러 정책별로 캐시사이..

앞서 physical memory의 한계를 극복하기 위해 main memory를 hard disk의 캐시처럼 사용하는 demand paging을 살펴보았다. 이제 demand paging에서 메인 메모리가 부족할 때 전에 캐싱된 내용의 변경(swapping)이 어떤 정책으로 일어나는지를 살펴보자. average memory access time (AMAT) TM = Memory Access Latency TD = Disk Access Latency Pmiss = 1 - Phit 위의 수식에서 알 수 있듯이 hit ratio는 전체 성능에 큰 영향을 주고, 이 hit ratio에 큰 영향을 주는 것이 교체 정책이다. 교체 정책 (page replacement policies) 1. Optimal polic..

메모리 계층 구조 1. cpu의 register = 가장 빠른 저장공간 2. 캐시 메모리 3. 메인 메모리 (DRAM) 4. 굉장히 큰 용량의 저장 장치 (하드디스크, 테이프 등..) demand paging 앞서 paging의 속도가 느린 이슈는 TLB로 해결하고, page table이 너무 큰 이슈는 hybrid/ multi level paging으로 해결했다. 그럼 physical memory 자체의 용량이 부족한 한계점은 어떻게 해결할 수 있을까? 바로 메인메모리를 하드디스크의 캐시처럼 사용하는 demand paging을 통해 우리는 거의 무한대에 가까운 virtual momory공간을 확보할 수 있다. 메인메모리의 내용이 캐시메모리에 캐싱되는 것처럼, 하드디스크의 내용이 메인메모리로 캐싱될 수 ..

paging base and bound, segmentation과 구분되는 paging의 장점은 고정된 페이지 크기를 사용하여 메모리 관리가 편리하다는 점이다. 하지만 주소변환정보를 담고 있는 page table과 관련해서 두가지의 문제가 있다. 1. 속도의 문제 page table이 물리적 메모리에 위치하고 있기 때문에, 하나의 명령어를 수행하기 위해 여러번 메모리에 접근해야 해서 속도가 느림. >> 이것은 TLB로 해결할 수 있다. 2. 크기의 문제 page table에서 VPN를 인덱스로 PFN를 담고있는 entry를 가져오기 위해서는 페이지 테이블이 연속된 공간을 확보해야 한다. 그런데 page table이 너무 커진다. 그렇다고 page의 크기를 크게 하면, page table entry개수는 ..

데이터 중심 설계의 문제점 기본 매핑 예제를 보면 데이터베이스 테이블의 외래키를 객체에 그대로 가져오며 테이블 설계에 객체를 맞춘 것을 볼 수 있다. @Entity @Table(name = "ORDERS") //order가 예약어로 걸려있는 경우가 있어서 ORDERS로 많이 쓴다. public class Order { @Id @GeneratedValue @Column(name = "ORDER_ID") private Long id; @Column(name = "MEMBER_ID") private Long memberId; //누가 주문했는지. private LocalTime orderDate; @Enumerated(EnumType.STRING) private OrderStatus Status; } 그리고 ..

paging이 느린 이유와 TLB memory에 접근하기 위해 주소 변환을 하는데, 이 주소 변환 정보(page table)는 매우 커서 memory에 저장된다. 다시말해 memory에 접근하려고 주소변환을 하는데 그 정보가 또 메모리에 있는 것이다. 이 때문에 memory에 매번 추가로 한번 더 access해야한다. 그래서 이것을 빠르게 하고자 TLB(translation lookaside buffer)를 사용한다. TLB는 mmu안에 들어있고, 구조적으로는 캐시메모리이기 때문에 address translation cache라고도 부른다. 주소변환이란 앞서 설명했듯이 VPN를 PFN로 변환하는 과정이고, 여기서 캐시메모리를 사용하여 주소변환정보를 기억했다가 다시 사용하도록 하는 것이 TLB이다. TLB..

paging paging은 base and bound, segmentation과는 달리 address space를 고정된 크기로 나눈다. virtual memory(address space)의 이 고정된 크기의 한 단위를 page라고 하고, 이것을 실제로 가지고 있는 물리적 메모리에서는 slot, page frame, frame이라고 부른다. 왼쪽 그림과 같이 64 바이트의 address space를 addressing하려면 2^6 = 6비트가 필요하다. 페이지가 4개로 나뉘기 때문에 상위 2비트는 virtual page number를 가리키고(VPN) 나머지 4비트는 한 페이지 내에서 addressing하는데에 사용된다. 또 virtual address가 오른쪽 그림같은 실제 물리적 메모리의 어디에 저..