BLOG main image
분류 전체보기 (68)
excel.101 (0)
rewind (9)
(3)
(2)
목공 (3)
(3)
me2day (0)
The Ethereal Void (9)
코드 (14)
귀찮은것 (0)
Visitors up to today!
Today hit, Yesterday hit
daisy rss
tistory 티스토리 가입하기!
'JavaScript'에 해당되는 글 3건
2007. 11. 28. 20:13
뭐 관심이 있는 사람만 관심이 있을 뚱딴지같은 내용.

호출 스택입니다.

오래 전에 지뢰 찾기를 만들어 본적이 있었습니다. 기본적으로 빈 칸을 눌렀을 때, 주변에 연계된 모든 빈 공간이 열리는 부분은 현재 칸을 중심으로 팔방이 빈 공간인지를 조사해가며 열어나가면 되는데, 여기서 재귀 호출을 할 때 게임 영역이 일정 수준 이상이 되면, 스택 오버플로우가 일어나더군요.. 그래서 아래와 같은 테스트 코드를 작성하였습니다.

var sc = 0;
try
{
	(function recursive_stack_test()
	{
		recursive_stack_test(++sc);
	})();		
}
catch (e) 
{
	document.writeln("stack count -> " + sc);
}
 

현재 브라우져에서 위의 테스트를 누르면 결과가 나옵니다.. 몇몇 다른 블로그에서 확인한 결과 값과 조금 씩 다른데 그 현상에 대한 기록을 조사해 보았습니다.

먼저 IE의 경우에는 Eric Lippert에 따르면..
function context에 진입할 때마다 새로운 "activation" frame이 JScript 스택에 쌓이게 된다. 이 JScript 스택은 힙영역에 위치하기 때문에 그다지 문제가 되지 않지만, 이와 동시에 새로운 인터프리터의 사본도 생성되어 시스템 스택영역에 위치하게 되는데, 이는 수 백 바이트 정도를 차지하며, 가용한 시스템 스택의 크기가 1,000,000 Bytes 라고 할 때 순식간에 이 용량을 소비하게 된다..
라고 하였습니다. 직접 실시한 브라우져마다 테스트 결과는
  • Internet Explorer 6 : 900~1200
  • Internet Explorer 7 : 1700~
  • FireFox 2.0.0.4 : 1000 (1001) (!) 고정
  • FireFox 3.0b2pre : 245160 (Wow)
  • Opera 9.24 : 3300+
  • Safari 3.0.4 : 499 (500)
FireFox의 경우 1000 (fencepost 1001)에서 고정되는 현상은 버그질라에 많이 올라와 있습니다. 위에 3.0에 보시면 아시겠지만, 이미 버그 처리되어 수정된 사항입니다.

Safari의 경우 원래 제한이 100(fencepost)이었습니다. 몇몇 웹 어플(gmail 같은..)데서 "Maximum call stack size exceeded" 에러가 버그 리포팅되어 수정된 현재가 500입니다. (근데 이것도 모자르지 않나요?)

기본적으로 FireFox 3.0b2pre를 제외하고는 상황에 따라서는 고정된 재귀 호출 스택 제한을 고려해야 됩니다. 특히 Safari의 경우는 문제가 좀 있죠. :(

참고가 되셨으면 합니다.
반응형
2007. 3. 22. 01:53
자야되는데 잠은 오질 않고 새벽 두시가 다 되어간다. 개인적으로 매력인 언어로만 생각하고 있었지, 그 속의 무수한 내용들을 아직 인지가 부족하다. Ajax 책은 많이 나왔지만, 그 역시도 조금 더 나은 스크립팅 팁의 수준에서 머물고 있다.

정말 이렇게 대중적이면서 평가절하되고 몰이해되는 언어가 또 있을까 생각을 해보았다. 일전에 VBscript 대신 Jscript로 Server Page를 작성하면서, Server-Side 언어로써 JavaScript가 얼마나 매력적이면서 불완전한지를 경험한 적이 있었다. 그러면서도 계속 빠져드는건..? 알수가 없다.

Garbage Collector에 대한 내용을 정리중이다. 일단 가장 흔히 인지되고 있는 IE 메모리 누수현상중 순환참조에 대한 부분을 생각해 볼려고 한다.

먼저 순환 참조에 대한 일반적인 이해에는 Garbage Collector에 대한 간단한 작동 방식을 이해해야 된다.

다음 코드를 보자.
var Vervain = new Herb();
var Verbena = Vervain;
Vervena 가 객체 Vervain을 참조하게 되면 scope 내에 Vervain에 대한 참조카운트가 1이 증가한다. 그리고 실행이 끝나고, scope 를 벗어날 때 해당 scope 내에 Verbena는 파괴되게 된다. 그렇게 되면 Vervain 객체에 대한 참조카운트는 다시 1이 감소한다. 그렇게 되면 GC에서는 Vervain의 참조카운트가 0이 되었으므로 더 이상 사용하지 않는 객체로 판단하고 메모리를 해제하게 된다.

하지만 다음과 같은 경우는 어떨까?

var Vervain = new Herb();
var Verbena = new Herb();
Vervain.see = Verbena;
Verbena.see = Vervain;
Vervain과 Verbena는 서로를 참조하고 있다. 이러한 경우를 순환참조라고 한다. 객체에 대한 참조를 따라가 보면 완전한 연결고리를 형성하게 된다.

하지만 위와 같은 경우는 어떻게 메모리를 해제해야 될까? Vervain과 Verbena의 참조카운트는 모두 1이다. Vervain 를 해제하기 위해서는 Vervain에 대한 참조카운트가 0이 되어야 하는데, 이는 Verbena.see 가 Vervain을 참조하고 있다. 역으로 Verbena에 대한 참조카운트도 0이 되어야 하나 Vervain.see 는 Verbena를 참조하고 있다. 결국 이러한 순환참조는 메모리 누수현상을 가져오게 된다. (IE 7에선 이러한 문제가 해결되었다.) 이러한 메모리 누수현상을 방지하기 위해서는 위와 같은 순환 참조를 형성하지 않거나, Vervain.see = null 혹은 Verbena.see = null 을 할당함으로써 참조카운트를 0으로 만들어 GC에서 메모리를 해제하게끔 만들어야 한다.




반응형
2007. 3. 21. 14:01
FireFox 에는 onpropertychange event가 없다.
IE에서 DOM element의 값 변경사항 등을 감시하는데, 다음과 같이 쓰인다.

IE 기준:
var ROFL = function() {
	if (event.propertyName == "value") {
		alert("I got ya!");
	}
}

var inputElement = document.getElementById("input"); 
inputElement.onpropertychange = ROFL;
inputElement.value = "snooping..";


하지만, FF에는 onpropertychange 이벤트가 없다. 한참 고민을 하던 중에 예전에 Netscape에는 변수의 변화를 감시할 수 있는, watch, unwatch 가 있었다. 이 놈들이 DOM element 에도 적용이 되는지 테스트해보았다.

var header = document.getElementById("header");
header.watch("id", function(id, xn, xp) {
    alert(id + "," + xn + "," + xp);
});
header.id = ":)";
header.unwatch("id");

header.style.watch("width", ....);
header.style.width = "100px";
header.style.unwatch("width");

된다. :)
그러나, 확인되야 될 사항이 있다.

  1. closures 사용에 따른 메모리 유출.
  2. 감시되고 있는 객체가 삭제될 경우.
  3. unwatch 를 사용하지 않을 경우 메모리 유출.


반응형
prev"" #1 next