Changeset 47959 in webkit for trunk/JavaScriptCore/interpreter

Timestamp:

Sep 2, 2009, 2:49:31 AM (16 years ago)

Author:

[email protected]

Message:

2009-09-02 Norbert Leser <​[email protected]>

Reviewed by Eric Seidel.

Use fastMalloc when neither MMAP nor VIRTUALALLOC are enabled

RegisterFile constructor currently throws #error when both
MMAP and VIRTUALALLOC conditions fail.
On any platform that does not provide these features
(for instance, Symbian),
the fallback should be regular malloc (or fastMalloc).
It is functionally equivalent in this case, even though it may
have certain drawbacks such as lack of dynamic pre-allocation.

• interpreter/RegisterFile.cpp: (JSC::RegisterFile::~RegisterFile):
• interpreter/RegisterFile.h: (JSC::RegisterFile::RegisterFile):

Location:

trunk/JavaScriptCore/interpreter

Files:

• RegisterFile.cpp (modified) (1 diff)
• RegisterFile.h (modified) (1 diff)

trunk/JavaScriptCore/interpreter/RegisterFile.cpp

@@ -39 +39 @@
     VirtualFree(m_buffer, 0, MEM_RELEASE);
 #else
-    #error "Don't know how to release virtual memory on this platform."
+    fastFree(m_buffer);
 #endif
 }

trunk/JavaScriptCore/interpreter/RegisterFile.h

@@ -205 +205 @@
         }
         m_commitEnd = reinterpret_cast<Register*>(reinterpret_cast<char*>(m_buffer) + committedSize);
-    #else
-        #error "Don't know how to reserve virtual memory on this platform."
+    #else 
+        /* 
+         * If neither MMAP nor VIRTUALALLOC are available - use fastMalloc instead.
+         *
+         * Please note that this is the fallback case, which is non-optimal.
+         * If any possible, the platform should provide for a better memory
+         * allocation mechanism that allows for "lazy commit" or dynamic
+         * pre-allocation, similar to mmap or VirtualAlloc, to avoid waste of memory.
+         */
+        m_buffer = static_cast<Register*>(fastMalloc(bufferLength));
     #endif
         m_start = m_buffer + maxGlobals;