GPS 원리 요약

Dev 2010. 6. 27. 14:58

GPS 시스템의 구성
우주부분, 제어부분, 사용자부분으로 구성된다.

우주부분
GPS 위성들은 현재 시각과 위성의 궤도 정보(ephemeris)를 50bps 속도로 지속적으로 방송한다.

제어부분
GPS 위성을 관리하는 본부에서 GSP 위성들의 시각을 동기화 하고 궤도정보(ephermeris)를 조정한다. GPS 위성들은 아주 정밀한 시계를 갖고 있으며 같은 시간을 공유한다.

사용자부분
GPS 수신기의 시계를 이용해서 수신기의 현재 시간과 위성이 발송한 시간과의 차이를 구하면 위성과 사용자의 거리를 파악할 수 있다. 위성과 수신기 사이의 거리는 우주적인 거리다. 전파가 빛의 속도로 위성을 떠나 수신기 까지 도달할 때까지 유의미한 시간이 소요된다. 위성과 수신기는 같은 시계를 공유하고 있기 때문에 전파가 도착할 때까지 소요된 시간을 측정하면 위성과 수신기 사이의 거리를 구할 수 있다 (거리 = 시간 * 속도).
3개 이상의 위성과 수신기 사이의 거리를 파악하면 3각측량법을 이용해서 사용자의 위치를 판단할 수 있다.

Posted by ingeeC
,

NDK 언제 쓰나?

Dev 2010. 6. 11. 00:46
언제 안쓰나?
NDK는 어플리케이션 패키지에 네이티브코드를 포함시킬 수 있도록 제공되는 도구다. 단말에 내장되는 엔진 성격의 시스템을 만드는데는 적합하지 않다. 단말에 내장되는 엔진 성격... 좀 설명이 거시기한데... 암튼 공장에서 단말을 찍어낼 때 포함되는 바이너리를 만들 때에는 NDK를 고려할 필요가 없다. 그런 모듈은 활용 가능한 모든 라이브러리를 끌어모아 최고의 성능을 추구해야 한다.

언제 쓰나?
어플리케이션을 만들 때 사용한다. NDK는 포터블을 염두에 두고 구글이 버전을 관리한다. NDK로 만든 네이티브 코드는 개념상 컴파일만 다시하면 모든 단말에서 실행을 보장한다. 포터블해야 하는 어플리케이션을 만들 때, 자바로 해결할 수 없는 성능 이슈가 있다면 NDK를 사용한다. 어쨌든 NDK를 쓰는 어플리케이션이 추구하는 목표는 성능/기능보다는 가능한 모든 안드로이드 단말에서 실행시킬 수 있는 '이식성 (portability)'이다.
Posted by ingeeC
,

http://android-developers.blogspot.com/ 블로그에서 NDK를 키워드로 기사를 검색해서 4개의 포스트를 찾았다. 4개 기사의 내용을 요약한다. 영어다. 갑갑한가? 나는 환장하겠다. 당분간 영어로 포스트를 올리게 될 것 같다. -_-;;


http://android-developers.blogspot.com/2010/05/android-22-and-developers-goodies.html
"Android 2.2 and developers goodies."
Posted by Xavier Ducrohet, Android SDK Tech Lead on 20 May 2010 at 9:00 AM
 - 20/May/2010 Android 2.2 announced. (7th platform release since Android 1.0)
 - (on the native side,) add new APIs to access Skia bitmap
 - tools update
  - Android SDK Tools, Revision 6, Eclipse plug-in 0.9.7
  - Android NDK, Revision 4

http://android-developers.blogspot.com/2010/03/android-ndk-r3.html
"Android NDK r3"
Posted by David Turner on 08 March 2010 at 11:25 AM
 - NDK r3 can used to target devices running Android 1.5 and higher
 - use GCC 4.4.0 (previously used GCC 4.2.1)
  so, generate slightly more compact and efficient machine code
 - support OpenGL ES 2.0

http://android-developers.blogspot.com/2009/09/now-available-android-16-ndk.html
"Now available: Android 1.6 NDK"
Posted by David Turner on 29 September 2009 at 10:00 AM
 - NDK is a companion to SDK
 - NDK is used to generate and embed ARM machine code within your App Package
 - NDK 1.6 features
  - support OpenGL ES 1.1
  - many fixes to the NDK build scripts

http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html
"Introducing Android 1.5 NDK, Release 1"
Posted by David Turner on 25 June 2009 at 10:30 AM
 - finally, android App-developers can use native code for their App
 - provide libc, libm, JNI, libz, and liblog libraries


(끝)

Posted by ingeeC
,

JavaScriptCore 현황

(JSC SquirrelFish, SFX의 관계에 관해)

 

 

요약

l  SquirrelFish SquirrelFishExtreme(SFX) JavaScriptCore의 아키텍처를 개선하여 실행성능을 향상시킬 목적으로 WebKit 엔지니어들이 시작한 프로젝트의 코드네임

n  SquirrelFish bytecode VM 방식을 구현하기 위해 시작한 프로젝트

n  SFX (SquirrelFishExtreme) native code JIT 방식을 구현하기 위해 시작한 프로젝트

l  2008 6 SquirrelFish WebKit SVN trunk에 통합됨

n  (SquirrelFishWebKit SVN main trunk에 통합된) 현재 상황에서 JSC SquirrelFish, SFX는 동일함

l  현재 Linux ARM JIT는 지원하나 WinCE ARM JIT는 지원하고 있지 않음

 

 

WIKI 백과 중에서
http://en.wikipedia.org/wiki/WebKit#JavaScriptCore

l  2008/6/2 WebKit 프로젝트가 JavaScriptCore“SquirrelFish (bytecode interpreter)” rewrite 했음을 발표함

l  2008/9/18 x86 JIT (SFX: SquirrelFishExtreme)를 발표함

l  2009/1 Mac OSX on x86-64 JIT 발표함

 

 

뉴스그룹 중에서

2008/5/18/공지
http://old.nabble.com/The-SquirrelFish-Cometh-to17298445.html#a17298445

l  기존 JavaScriptCore AST 기반 인터프리터였다. 성능에 관한 아키텍처적 문제가 있었다

l  그래서 bytecode VM 아키텍처의 SquirrelFish 프로젝트를 시작했다

l  별도의 SVN repository에서 작업을 진행했으나 조만간 main trunk에 통합할 것이다

 

2008/6/98/질문: WebKitGtk 최신 소스에 SquirrelFish JS-engine이 적용되어 있는가?
http://old.nabble.com/Get-SquirrelFish-for-Webkit-in-linux-to17724999.html#a17724999

ð  2주전에 merge됐다.

 

2008/6/13/공지
http://old.nabble.com/JavaScriptCore-directory-reorganization-to17816031.html#a17816031

l  SquirrelFish가 완료되어 SVN trunk JavaScriptCore 디렉토리를 변경한다

 

2008/12/24/질문: SFX non-x86 JIT를 지원하는가?
http://old.nabble.com/SquirrelFish-Extreme-for-non-x-86-platforms-td21159116.html

ð  JIT는 아직 x86만 지원한다

ð  JIT를 기타 CPU로 포팅하는 것을 고려 중이다

ð  JITbytecode 모델보다 효율적일지 판단 중이다. JIT는 메모리를 압도적으로 많이 사용한다

 

2009/12/11/질문: WinCE JIT 어찌되어 가나?
http://old.nabble.com/JIT-on-Windows-CE-to26740395.html#a26740395

ð  개발 중이다.

 

 

 

(이상입니다.)

 


Posted by ingeeC
,

웹킷 세미나

Dev 2009. 12. 18. 05:37

구글 엔지니어가 소개하는 웹킷

http://blog.taicki.org/2009/12/rendering-in-webkit.html

 

이 글은 스프링노트에서 작성되었습니다.

Posted by ingeeC
,

JavaScriptCore 분석

Dev 2009. 12. 10. 17:50
간단한 내용이지만 고생하는 누군가에게 도움이 되면 좋겠다.


JavaScriptCore 분석

(WebKit rev 50723 기준)

 

JavaScriptCore 관련 소식/ ARM JIT 현황

l  JSC 소스에 PLATFORM(ARM_THUMB2), PLATFORM(ARM_TRADITIONAL) 컴파일 플랙에 대한 구현부가 존재한다.

l  WM6 포트에 적용할 수 있는지는 테스트해봐야 안다.

l  관련 뉴스 그룹 기사

n  2009/06/09: ARM JIT 릴리즈 됐다.
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514> )

n  2009/10/22: WinMobile에서는 안된다.
The current implementation is designed for Linux

n  2009/04/01: ARM port of JIT 공시
on a Nokia N810, and we gained 13% performance improvement. The memory consumption is increased by 3.3%.

 

 

JSC Class Diagram


 

다이어그램이 나타내는 내용 몇 가지를 다음과 같이 요약한다.

l  페이지의 root Frame WebView 1:1 관계다.

n  동일한 WebView에서 페이지를 이동할 때, root Frame 인스턴스는 유지된다.

n  페이지에 따라 sub Frame들이 필요할 때가 있는데 sub Frame들은 페이지 이동시 생성되거나 소멸된다.

n  sub Frame의 소멸은 Cache 때문에 즉각적으로 이루어지지 않는다.

l  Frame의 멤버로 ScriptController 인스턴스가 존재한다.

n  ScriptController WebCore 세계에서 JSCore를 쉽게 호출하도록 캡슐화(창구를 단일화)하는 역할을 한다.

n  WebCore가 페이지를 처리할 때, HTMLTokenParser JavaScript 소스 코드를 만나면 ScriptController::evaluate() 메소드를 호출한다. 그것으로 WebCore JSCore 사이의 모든 연결이 끝난다.

l  JSGlobalData는 싱글톤 객체로 system wide하게 1개 존재하며, 시스템과 life-cycle을 같이 한다.

n  JSGlobalDataJSC 동작에 필요한 모든 것을 나타낸다 (Lexer, Parser, Interpreter, and Data).

l  JSC::GlobalObject의 실 구현체는 WebCore::JSDOMWindow 이다.

n  JSDOMWindow Frame에 속해 있다.

l  ExecState JSCore의 실행 상태에 관한 모든 것을 나타낸다.

n  Mostly, an ExecState represents the state of execution in the VM. (Geoffrey Garen)

n  ExecState JSGlobalObject에 의해 생성/초기화 되며, JSGlobalObject life-cycle을 함께 한다.

l  JSContextRef ExecState와 동일하다.

n  JavaScriptCore/API/ 폴더 아래 있는 JSC public API을 호출하기 위해 정의한 타입이다.

n  JSC public APIC based API 이다. 이 때문에 ExecState* 객체 타입을 JSContextRef 타입으로 변환해서 사용해야 한다. 타입 변환을 위해 toRef()toJS() 함수를 사용한다.

n  toRef() toJS() 함수는 타입 캐스팅만 수행하는 inline 함수다. 때문에 런타임 실행 오버헤드가 없다 (컴파일 타임에 처리됨).

 

 

JavaScript 소스코드 실행 시퀀스, 

JSGlobalObject& ExecState 생성/초기화 시퀀스


 

l  JS 코드가 없는 페이지에서는 JSGlobalObject ExecState가 생성/초기화 되지 않는다.

l  JSGlobalObject ExecState 인스턴스는 JS 코드가 존재하는 페이지에서만 생성/초기화 된다.

 

 

(이상입니다.)

 

Posted by ingeeC
,

WebKit 빌드 절차

Dev 2009. 11. 27. 10:01

웹킷 빌드 절차 요약

 

작년에 웹킷을 처음 빌드한지 1년이 지난 지금,

최신 웹킷 소스를 다운 받아 다시 빌드하게 됐다. 작년보다 빌드 절차가 다소 간소해졌다. 웹킷 프로젝트가 더욱 정돈되었구나 느꼈다. 개선됐다고 느낀 점은 다음 2가지다.

l  dos2unix 를 통해 웹킷 소스 파일들의 eol (end of line) 포맷을 바꾸어 주지 않아도 빌드가 됐다. 이는 웹킷 소스가 개선됐기 때문일 수도 있고 cygwin 같은 빌드에 사용되는 툴이 개선됐기 때문일 수도 있다.

l  Webkit.sln 파일을 열어 대부분의 프로젝트에 /wd4819 컴파일 옵션을 부여하는 절차를 생략해도 빌드가 됐다. DumpRenderTree 라는 프로젝트만 컴파일 옵션을 조정해주면 깔끔하게 빌드가 끝난다.

 

작년에 썼던 빌드 성공담은 http://ingeec.tistory.com/1 에서 확인할 수 있다.

빌드가 수월해지기는 했지만 여전히 약간의 산을 넘어야 한다. 덕분에 빌드만 끝내도 약간의 성취감(?)을 느낄 수 있다. 빌드 성공담을 공유한다. 아래의 빌드 절차는 Windows XP 32bit PC 위에서 수행했다.

 

 

1. 툴설치

웹킷 빌드에 필요한 툴들을 설치한다. 다음과 같은 툴들이 필요했다.

l  Cygwin

n  설치할 때 “all/ install” 옵션을 선택했다.

l  Tortoise

n  1.6.6.17493 (32bit): 2009.11.19. 현재 최신 버전이다.

l  VS 2005

n  2개의 PC에서 빌드해봤다. PC는 영문 버전을 사용했고, 다른 PC에서는 한글 버전을 사용했다. PC 모두 빌드하는데 문제 없었다.

l  QuickTime SDK

n  http://webkit.org/building/tools.html 페이지를 참조한다.

 

툴 관련 팁

l  Cygwin 콘솔에서 SVN 관련 메시지가 깨져 나올 때

ð  C:\cygwin\usr\share\locale 아래 있는 ko 폴더를 지우거나 다른 이름으로 바꾸면SVN 관련 메시지가 영문으로 출력된다. 한글은 아니지만 이상한 난수로 깨져나오는 것보다는 낫다.

l  VS2005 한글 버전을 쓸 때

ð  http://trac.webkit.org/wiki/BuildingOnWindows 페이지를 보면 VS2005 관련 서비스팩들을 깔아야 한다고 안내되어 있다. 그런데 그페이지에 가이드된 서비스팩들은 영문버전용이라서 그런지 한글 VS2005 위에는 설치되지 않았다. 서비스팩들을 깔지 않고 그냥 있는 그대로 시도해도 문제 없었다.

 

 

2. 소스 트리 작성

l  작업 디렉토리 아래 src 폴더와 out 폴더를 만들었다. 빌드를 위해 구축한 폴더 구조는 다음과 같다.

l  src 폴더는 WebKit 소스서버(http://svn.webkit.org/repository/webkit/trunk)로부터 최신 소스를 다운로드 받을 폴더이다. 이후 $(SrcHome) 이라고 언급하기로 한다.

l  out 폴더는 웹킷 소스를 빌드한 결과물을 담을 폴더이다.


 

3. WebKit 소스 체크아웃

l  “2009-11-09, rev 50632” 버전과 “2009-11-20, rev 51226” 버전으로 빌드 절차를 확인했다.

 

 

4. WebKitSupportLibrary.zip 다운로드 & 복사

l   http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html 

l  WebKitSupportLibrary.zip 파일을 다운로드 해서 $(SrcHome) 폴더에 복사한다.

 

 

5. 환경변수 등록

l  WEBKITOUTPUTDIR 환경변수와 WEBKITLIBRARIESDIR 환경변수를 등록한다.

l  WEBKITOUTPUTDIR 환경변수에는 임의의 path를 지정해도 되지만,
WEBKITLIBRARIESDIR
환경변수에는 WebKit 소스트리 안에 있는

$(SrcHome)\WebKitLibraries\win path
(Window Style) 지정해야 한다.

l  참고로 필자는 Cygwin bash에서 환경변수 등록을 위해 다음과 같은 스크립트 파일을 사용했다.

 

스크립트 파일 (webkitenv.sh) 내용

export WEBKITOUTPUTDIR=E:\\Work\\webkit\\out

export WEBKITLIBRARIESDIR=E:\\Work\\webkit\\src\\WebKitLibraries\\win

 

스크립트 파일을 이용한 환경변수 등록 절차 (cygwin bash 콘솔출력)

ingee@ingeedev ~

$ pwd

/cygdrive/e/Work

 

ingee@ingeedev ~

$ cd webkit/

 

ingee@ingeedev ~/webkit

$ source webkitenv.sh

 

ingee@ingeedev ~/webkit

$ env |grep WEBKIT

WEBKITLIBRARIESDIR=E:\Work\webkit\src\WebKitLibraries\win

WEBKITOUTPUTDIR=E:\Work\webkit\out

 

ingee@ingeedev ~/webkit

$

 

 

 

6. update-webkit 스크립트 실행

l  $(SrcHome)/WebKitTools/Scripts/update-webkit 스크립트를 실행하여 소스를 업데이트 한다.

 

cygwin bash 콘솔출력

ingee@ingeedev ~/webkit/src

$ pwd

/cygdrive/e/Work/webkit/src

 

ingee@ingeedev ~/webkit/src

$ ls WebKitSupportLibrary.zip

WebKitSupportLibrary.zip*

 

ingee@ingeedev ~/webkit/src

$ WebKitTools/Scripts/update-webkit

Updating OpenSource

U    WebCore/rendering/style/StyleRareNonInheritedData.h

U    WebCore/rendering/style/RenderStyleConstants.h

U    WebCore/rendering/style/RenderStyle.h

U    WebCore/rendering/RenderThemeWin.cpp

A    LayoutTests/fast/forms/script-tests/ValidityState-stepMismatch-range.js

A    LayoutTests/fast/forms/script-tests/input-type-change3.js

A    LayoutTests/fast/forms/script-tests/ValidityState-typeMismatch-datetime.js

A    LayoutTests/fast/forms/ValidityState-typeMismatch-date-expected.txt

U    WebKitSite/ChangeLog

U    WebKitSite/css/main.css

U    WebKitSite/coding/coding-style.html

U    WebKitSite/coding/commit-review-policy.html

U    WebKitSite/security/security-group-members.html

 U   .

Updated to revision 51372.

Checking Last-Modified date of WebKitAuxiliaryLibrary.zip...

Current WebKitAuxiliaryLibrary is up to date

 

ingee@ingeedev ~/webkit/src

$

 

 

7. 빌드 스크립트 실행

l  WebKitTools/Scripts/build-webkit –debug 스크립트를 실행한다.

l  build-webkit 스크립트를 실행하면 FAIL 이라는 메시지가 뜬다. 하지만 이상태에서도 out 폴더를 확인해보면 WebKit.dll 을 비롯 필요한 모든 결과물이 생성된 것을 확인할 수 있다. FAIL이 난 것은 WebKit 관련 여러 프로젝트중 DumpRenderTree 라는 유틸리티 프로그램 프로젝트 뿐이다.

 

cygwin bash 콘솔출력

ingee@ingeedev ~/webkit/src

$ pwd

/cygdrive/e/Work/webkit/src

 

ingee@ingeedev ~/webkit/src

$ WebKitTools/Scripts/build-webkit –-debug

Checking mod-date of WebKitSupportLibrary.zip...

 

Installing WebKitSupportLibrary...

The WebKitSupportLibrary has been sucessfully installed in

 /cygdrive/e/Work/webkit/src/WebKitLibraries/win

Building results into: /cygdrive/e/Work/webkit/out

WEBKITOUTPUTDIR is set to: E:\Work\webkit\out

WEBKITLIBRARIESDIR is set to: E:\Work\webkit\src\WebKitLibraries\win

/cygdrive/e/Work/webkit/src/WebKitTools/Scripts/pdevenv /useenv win\WebKit.vcproj\

WebKit.sln /build Debug

15>DumpRenderTree.cpp

15>LayoutTestControllerWin.cpp

15>E:\Work\webkit\src\WebKitLibraries\win\Include\ConditionalMacros.h : error C2220: warning treated as error - no 'object' file generated

15>E:\Work\webkit\src\WebKitLibraries\win\Include\ConditionalMacros.h : warning C4819: The file contains a character that cannot be represented in the current code page (949). Save the file in Unicode format to prevent data loss

15>DumpRenderTree - 1 error(s), 3 warning(s)

========== Build: 14 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========

 

===== BUILD FAILED ======

Please ensure you have run WebKitTools/Scripts/update-webkit to install dependencies.

 

You can view build errors by checking the BuildLog.htm files located at:

/cygdrive/e/Work/webkit/out/obj/<project>/<config>.

 

ingee@ingeedev ~/webkit/src

$

          

l  FAIL 메시지는 DumpRenderTree 프로젝트에서 발생한 것이다. 다음 단계 절차에 따라 해결할 수 있다.

 

 

8. C4819 컴파일 에러 해결

l  DumpRenderTree 프로젝트의 C4819 에러를 해결하기 위해 DumpRenderTree 프로젝트의 컴파일 옵션을 수정한다.

l  $(SrcHome)\WebKit\win\WebKit.vcproj\WebKit.sln VS2005 솔루션 파일을 오픈한다.
솔루션 파일을 열기전에 Windows 시스템에 WEBKITOUTPUTDIR 환경변수와

WEBKITLIBRARIESDIR
환경변수가 등록되어 있는지 확인하자. 지금까지 Cygwin 콘솔에서만 작업했다면 Windows 시스템에는 해당 환경변수들이 등록되어 있지 않을 것이다.

l  DumpRenderTree 프로젝트의 all configuration Compile Option으로 /wd4819 부여한다.

 

 

9. 다시 빌드

l  WebKitTools/Scripts/build-webkit --clean 스크립트를 실행한다.

l  WebKitTools/Scripts/build-webkit --debug 스크립트를 실행한다.

 

cygwin bash 콘솔출력

ingee@ingeedev ~/webkit/src

$ pwd

/cygdrive/e/Work/webkit/src

 

ingee@ingeedev ~/webkit/src

$ WebKitTools/Scripts/build-webkit –-clean

17>파일 삭제 - E:\Work\webkit\out\obj\JavaScriptCore\DerivedSources\RegExpObject

.lut.h

17>파일 삭제 - E:\Work\webkit\out\obj\JavaScriptCore\DerivedSources\StringProtot

ype.lut.h

17>파일 삭제 - E:\Work\webkit\out\obj\JavaScriptCore\DerivedSources\docs\bytecod

e.html

========== Clean: 17 succeeded, 0 failed, 0 skipped ==========

 

ingee@ingeedev ~/webkit/src

$ WebKitTools/Scripts/build-webkit --debug >buildlog.txt

 

ingee@ingeedev ~/webkit/src

$

          

l  빌드가 성공했다. 빌드하면서 생성한 buildlog.txt 파일을 첨부한다.

 

 

빌드 팁 (몇가지 문제와 대처방법)

l  qmake 를 찾는 에러가 날 때

 

cygwin bash 콘솔출력

ingee@ingeenote /cygdrive/d/work/webkit/src

$ ./WebKitTools/Scripts/build-webkit --debug > buildlog.txt

Use of uninitialized value $defaults in pattern match (m//) at /cygdrive/d/work/

webkit/src/WebKitTools/Scripts/webkitdirs.pm line 795.

Can't exec "qmake": No such file or directory at /cygdrive/d/work/webkit/src/Web

KitTools/Scripts/webkitdirs.pm line 1217.

Use of uninitialized value $mkspec in scalar chomp at /cygdrive/d/work/webkit/sr

c/WebKitTools/Scripts/webkitdirs.pm line 1217.

sh: qmake: command not found

Failed to setup build environment using qmake!

 

          

ð  Qt 버전으로 빌드하려 했기 때문이다. build-webkit 스크립트를 분석한 결과, cygwin 환경변수중에 QTDIR이 정의되어 있으면 Qt 버전으로 빌드하려 한다는 것을 알았다. cygwin bash 콘솔에서 unset QTDIR 하여 QTDIR 환경 변수를 제거하면 해결된다.

 

 

l  unicode/uchar.h, pthread.h 등의 헤더 파일을 못찾을 때

 

cygwin bash 콘솔출력

ingee@ingeenote /cygdrive/d/work/webkit/src

$ ./WebKitTools/Scripts/build-webkit –debug

2>------ Build started: Project: WTF, Configuration: Debug Win32 ------

2>Performing Pre-Build Event...

2>/usr/bin/bash

2>Compiling...

2>CollatorDefault.cpp

2>e:\Work\webkit\src\JavaScriptCore\wtf/unicode/icu/UnicodeIcu.h(27) : fatal error

C1083: Cannot open include file: 'unicode/uchar.h': No such file or directory

2>FastMalloc.cpp

2>..\..\wtf\FastMalloc.cpp(83) : fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory

          

ð  WEBKITLIBRARIESDIR 환경변수가 잘못 지정됐기 때문이다.
WEBKITOUTPUTDIR
환경변수에는 임의의 path를 지정해도 되지만
,
WEBKITLIBRARIESDIR
환경변수에는 WebKit 소스트리 안에 있는

$(SrcHome)\WebKitLibraries\win path
(Window Style) 지정해야 한다.

 

 

(이상입니다.)

 

 

Posted by ingeeC
,

JSC Opaque-type에 대하여

Dev 2009. 8. 25. 11:30
웹킷 JavaScriptCore 소스를 보면 JSValue 타입이 있고, JSValueRef 타입이 있다. 그리고 그 둘 사이에 형변환을 처리하는 toRef() 함수와 toJS() 함수가 제공된다. JSC에는 JSxxxxRef 스타일의 타입들이 몇개 더 있는데, 다음과 같다. JSValueRef, JSObjectRef, JSContextRef, JSGlobalContextRef, JSStringRef, JSClassRef.

웹킷 소스코드에서 JSValueRef와 JSObjectRef의 선언을 보면 다음과 같다.
typedef const struct OpaqueJSValue* JSValueRef;
typedef struct OpaqueJSValue* JSObjectRef;

그런데 소스코드 어디에도 struct OpaqueJSValue에 대한 정의는 없다.
OpaqueJSValue는 이름이 의미하듯 JSValue를 위한 모호한(Opaque) 타입이다.
위 JSValueRef와 JSObjectRef 선언 구문이 의미하는 바는 "JSValueRef is not JSObjectRef", 그리고 "JSObjectRef is JSValueRef" 이다. 즉, JSValueRef를 인자로 쓰는 모든 함수에는 JSObjectRef 변수들도 전달할 수 있지만, JSObjectRef를 인자로 쓰는 함수에는 JSValueRef 변수를 전달할 수 없다는 의미다.

JSC에는 JSValue* 타입과 JSObject* 타입을 인자로 쓰는 구현부와 JSValueRef 타입과 JSObjectRef를 인자로 쓰는 구현부가 달리 존재한다. 논리적인 이유에 의해 구분된 것이 아니고, 역사적인 이유에 의해 구분된 것이라 추측한다. 명쾌한 답은 찾지 못했다. 누군가 댓글이나 피드백으로 일러주면 고맙겠다.



(끝)
Posted by ingeeC
,

WebKit 메모리 릭에 대해

Dev 2009. 8. 13. 12:41

PC에서 Visual Studio 디버그 모드로 웹킷을 실행시켰다 종료시키면 기절할 정도로 많은 메모리 leak이 보고된다.
처음엔 명성 높은 웹킷 소스에서 그토록 많은 leak이 쏟아진다는 것이 믿어지지 않았다. 처음 프로그래밍을 배울 때 메모리 leak은 하나도 남김 없이 제거해야 할 절대 악으로 배웠다. 그래서 메모리 leak에 대해서는 강박관념에 가까운 혐오를 갖고 있다. 그런데 결론을 말하자면 WebKit 소스가 종료시 내는 leak은 의도적인 것이라고 한다. 종료 시점에 사용하던 메모리를 해지하는 절차를 생략함으로써 (해당 절차를 OS에게 맡김으로써) 처리 속도를 높이는 것이 설계 취지란다. 딱히 반박할 수도 없고... 경우에 따라서는 합리적인 판단일 수도 있겠다 하고 수긍하고 있다. 관련된 뉴스 그룹 기사는 다음과 같다.

http://www.nabble.com/freeing-static-variables-to24714380.html


뉴스 그룹 기사를 요약하면 다음과 같다.

static global 변수의 leak은 의도적이다 (by "Adam Treat-2")
* 웹킷은 static global 변수의 해지(clean up)에 관여하지 않는다. 해당 작업은 OS에게 맡긴다.

의도적인 leak에 대한 태클 (by "Zoltan" and "Antonio Gomes")
* 보고되는 leak이 너무 많아, 실제 주의해야 할 개발자의 실수에 의한 leak을 알아내기 어렵다.
* WebKit을 어플리케이션 형태가 아닌 다른 어플리케이션의 플러그인 형태로 사용할 경우, WebKit 플러그인을 내릴 때 leak이 발생하면 문제가 된다.


참고를 위해 뉴스 기사 원문을 아래와 같이 첨부한다.

_______________________________________________
freeing static variables 
by Zoltan Herczeg Jul 29, 2009; 05:05pm

Hi all,

Valgrind reports a lot of memory leaks when QtLauncher quits, because many
static local variables are not freed. I did a little research and realized
there is no consistent way to define static variables in webkit:

WebCore/css/CSSSelector.cpp: CSSSelector::extractPseudoType()
   using a DEFINE_STATIC_LOCAL() macro

WebCore/bindings/js/JSDOMWindowBase.cpp:
JSDOMWindowBase::commonJSGlobalData()
   static JSGlobalData* globalData;

WebCore/platform/qt/CursorQt.cpp:
   Cursors* Cursors::s_self = 0; (no static keyword)

I belive it would be a good thing to define a template for static
variables, which can (optionally) free static variables (enabled in debug
mode, but sometimes it would be good to enable it in release mode as well)

And I am wondering whether it would be worth to free (some) static
variables if they are used in a given time period. This may help to reduce
the memory consumption in the long run. This would be an optional feature,
an extra flag (or timeout value) for the template, which can be enabled or
disabled at compile time. If disabled, the value of this flag is not used
at all.

Regards
Zoltan


_______________________________________________
Re: freeing static variables 
by Zoltan Herczeg Jul 30, 2009; 03:55pm

Hi,

any thoughts on this? I hope my qestion was clear :) I would like to pack
the static declarations into wrapper classes, so we can add platform
and/or compilation mode (debug/release) dependent functionality to all
static variables (i.e: freeing them on exit).

Zoltan


_______________________________________________
Re: freeing static variables 
by tonikitoo (Antonio Gomes) Jul 30, 2009; 11:06pm

Zoltan, I think it would be a great add from a embedder-dev point of view.

Particularly, such leaks have been faced here in a soon past, when we
were loading a webkit browser as a plugin, and not as an application
by itself. So, we the webkit plugin was unloaded, it used to left
behind lots of leaks affecting the (main)  loader application, and as
we you might imagine many of this leaks were from global vars
(including in dependency libs , e.g. fontconfig =/)

--Antonio Gomes


_______________________________________________
Re: freeing static variables 
by Adam Treat-2 Jul 30, 2009; 11:26pm

On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote:
> Hi,
>
> any thoughts on this? I hope my qestion was clear :) I would like to pack
> the static declarations into wrapper classes, so we can add platform
> and/or compilation mode (debug/release) dependent functionality to all
> static variables (i.e: freeing them on exit).
>
> Zoltan

I've tried this before and it didn't work out so well.  The order in which you
free them becomes very important and error prone.  

And, of course, whatever solution you make has to be optional and easy to
maintain as the default policy in WebKit is to not care - by design - about
cleaning up after static globals on exit as that is left to the OS.

Another strategy for the embedded case where you want to free everything on
exit is to create a custom memory handler that will do this for you.

Cheers,
Adam


_______________________________________________
Re: freeing static variables 
by Zoltan Herczeg Aug 05, 2009; 12:10am

Hi Adam,

thank you for your suggestions. I have something similar in my mind.

I have opened a bugzilla entry and submited an early patch draft about my
concept:
https://bugs.webkit.org/show_bug.cgi?id=27980

The patch frees memory objects in a reversed creation order, and seemed
working well with QtLauncher (although only a subset of static variables
are freed right now). Do you know about special cases when this approach
is not enough?

Actually it is hard to find real memory leaks in the output of valgrind
because many of them are related to static variables. I hope this feature
will help to the leak hunters in the future.

Cheers,
Zoltan

 (끝)

Posted by ingeeC
,
JavaScriptCore를 변형해 쓰기 위해 분석하고 있다. 다음은 JSC에 관한 간단한 클래스 다이어그램이다. 웹킷을 사용하는 엔지니어들에게 도움이 되면 좋겠다.


다음은 JSC관련 객체들의 라이프사이클에 관한 메모이다.
  • WebCore::JSDOMWindow 인스턴스는 (다시 말해 JSC::JSGlobalObject 인스턴스는) 페이지를 새로 로드할 때마다 새로 만든다.
  • JSC::GlobalData 인스턴스는 application과 life-cycle을 같이 한다 (즉, 한번 만들면 어플리케이션을 종료시킬 때까지 같은 놈을 사용한다).

 (끝)

Posted by ingeeC
,