What is run-time constant pool and method-area in java.I read that JVM creates both of them but which one comes first in existence? Also what they contain? Any help will be greatly appreciated.
As per the http://www.artima.com/insidejvm/ed2/jvm2.html
Method area
Some runtime data areas are shared among all of an application's threads and others are unique to individual threads. Each instance of the JVM has one method area and one heap. These areas are shared by all threads running inside the VM. When the VM loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area.
Runtime Constant Pool
A class file keeps all its symbolic references in one place, the constant pool. Each class file has a constant pool, and each class or interface loaded by the Java virtual machine has an internal version of its constant pool called the runtime constant pool . The runtime constant pool is an implementation-specific data structure that maps to the constant pool in the class file. Thus, after a type is initially loaded, all the symbolic references from the type reside in the type's runtime constant pool.
Related
I saw that the default LocationStrategy is STRONG, which keeps a strong reference to the class loader when creating a ClassFileLocator. Does this mean Byte Buddy can prevent a class loader from being garbage collected (eg when undeploying a webapp from a servlet container) or is there another mechanism to evacuate those?
Also in this regard- the documentation about the WEAK strategy says a ClassFileLocator will "stop working" after the corresponding class loader is garbage collected. What are the implications? How would a locator for a garbage-collected class loader be used?
You are right about your assertion. With a strong type locator, all TypeDescriptions will reference the class loader as dependent types are resolved lazily. This means for example that if you look up a type's field type, that type will only be loaded if you are using it for the first time what might never happen.
Typically, those type descriptions are not stored over the life time of a class being loaded. Since the class loader will never be garbage collected during a loading of one of its classes, referencing the class loader strongly does not render any issue. However, once you want to cache type descriptions in between multiple class loadings (what can make a lot of sence since some applications load thousands of classes using the same class loader), this might become a problem if a class loader would be garbage collected while the cache is still referencing the type description with the underlying class loader.
In this case, reusing the type descriptions will be problematic since no lazily referenced classes can be resolved after the class loader was garbage collected. Note that a type description might be resolved using a specific class loader while the class is defined by a parent of that class loader which is why this might be a problem.
Typically, if you maintain a cache of type descriptions per class loader, this should however not be a problem.
I meet a question about the interview test:
When a dll is loaded into memory, which part(s) can be shared between processes?
A. code segment
B. static variable global variable
C. external difinitions and references for linking
D. BSS segment
who can give me an answer and a clear explation?
Processes are actually isolated programs running multiple threads in an OS. Generally operating system policy says, All processes are memory isolated from each other.
Code Segment : [NOT SHARED]
BSS and Static Fields : [NOT SHARED]
Reason is very simple, why a operating system allow process A to access process B's binary? that's security and memory protection violation. process A could corrupt (if write access is given) process B memory.
what about External Definitions?
Here comes the interesting part, External definitions could be statically or dynamically linked.
statically linked library implies definitions are linked at compiled time and programs binary contains It's machine code.
dynamically linked implies definitions are linked just after user commands to load any program in memory. OS calls dynamic library loader to resolve external dependencies of the program by providing shared object's path.
This shared object is cached by operating system in a different page frame, and every time when a program demands for this library, It simply copy It's page frame to process's virtual memory; and do required dynamic linking. This way multiple process have same binary of a single library.
It save RAM memory and time in loading library from disk, Also dynamic linking reduces binary size of the program.
It is also possible that the OS choose to load library again from disk, and thus make two copies of same library. This is a part of dynamic linking operation. I don't go into more depth, but if you are really interested https://en.wikipedia.org/wiki/Dynamic_linker or just ping me in comments section.
But regarding BSS and static fields, It is again not shared; Whenever a write operation is performed on such region (which is shared). Operating System create a new copy of that region for the other process. This makes sure that both process have their own copy of BSS and static fields.
Is there a good way to enforce that only one instance of my COM object (served by an in-process server) may be created at any one time?
Currently I am creating a Windows Mutex in the constructor of TMyObjectImpl; and if the mutex already exists then I set a flag to put my object into a "dead" state: when this flag is set, all implementations of interface functions will return an error code.
I would like to throw an exception instead of creating a "dead" object like this, however it is not good to throw C++ exceptions across a COM boundary and I'm not sure if the C++Builder implementation of COM can cope with this reliably.
There are actually two possible problem scenarios:
The same process creates two of MyObject
Two different processes create one each of MyObject
The Mutex guards against both of these.
My object factory function is:
static void createFactory()
{
new TCppAutoObjectFactory<TMyObjectImpl>(Comserv::GetComServer(),
__classid(TMyObjectImpl),
CLSID_MyObject,
Comobj::ciMultiInstance,
Comobj::tmSingle);
}
#pragma startup createFactory 32
According to the C++Builder DocWiki, setting the Instancing property has no effect for in-process servers - it always behaves like ciMultiInstance even if you specify ciSingleInstance.
My object needs this property because it access global resources (e.g. writes to a file in a specific disk location); the semantics of the object are such that there is only supposed to be one open at a time. I'm not looking to add support for multiple instances of my object.
I was wondering is there a way to load multiple instances of a DLL explicitly (i.e. with LoadLibrary call). Normally, a process loads a DLL just once when LoadLibrary is called (so that a single copy of the library resides in the process' memory) and all consequent calls of LoadLibrary done for the same library would be returning just the same handle of the library, returned by the very first call. To be more specific, I want to be able to load a separate instance of a DLL for each thread created inside of a process. Currently, if I do LoadLibrary in each thread, I just get the same pointer to a single instance of the library residing in the process' address space, and all threads in fact refer to the same functions from the library (here a big mess occurs in my app). Instead, I want each thread to create an individual instance of the library in a separate memory space so that the threads don't interfere with each other when calling functions from the library.
I don't think that is possible (until you create a new process and load the DLL in that process). DLLs are loaded at the process level (hence have entries in Process control block). Although your DLL can detect if new thread is created in the host application so that it can initialize TLS specific data in DLLMain method.
I have a VB6 DLL embedded in some ASP pages. The DLL hits a Codebase database, an obsure and obsolete database engine (a dialect/variation on dBase) that virtually no-one has even heard of. It takes Codebase nearly a second to initialise a new connection, which is unacceptably slow and so I've created a connection pool, managed by a VB class. The single instance of this class is created at the start of a VB module, i.e.:
Private m_codebaseManager As New CodebaseManager
My problem is that periodically the class initialization method is called again completely wrecking my pooling class and I've no idea why. Terminate does not fire and there's no sign of any crash occurring, so why on earth is initialize called? My understanding is that data in non-class modules persists for the lifetime of the DLL. Is that correct and if not, under what circumstances does a module 'restart'?
I would recommend removing the "New" from the variable declaration. Declaring a variable "As New" causes it to be checked every time it is referenced, and if set to Nothing a new instance of your CodebaseManager will be created.
A better solution would be to declare your variable like this:
Private m_codebaseManager As CodebaseManager
and then explicitly set it to a new instance when your application starts:
Set m_codebaseManager = New CodebaseManager
This means you can be sure you won't be creating any unintentional new instances of CodebaseManager. You'll probably then still have a bug but at least it will be an "Object or with block variable not set" error which you should be able to easily fix.
My understanding is that data in non-class modules persists for the lifetime of the DLL. Is that correct and if not, under what circumstances does a module 'restart'?
Sort of. Global state (module public/private vars) are apartment specific and is stored in TLS slots. VB6 supports apartment threading only, so each thread gets a "fresh" copy of the global state. Because ASP environment is multi-threaded so each thread gets a separate DB connection "pool".
If you need a real global state you have to use Application object to store it. If you put apartment threaded objects there (like VB6 ones) these can serialize you multi-threaded ASP environment and degrade performance. Use ADO objects or Dictionary objects or anything you are certain is free threaded.
Btw, you can let COM+ do the object/connection pooling for you. If OLEDB provider is a better one it can do connection pooling internally too (SQLOLEDB for MSSQL is an example).
But it's a DLL and not an ActiveX exe, so there's no Main() function and nowhere for the 'Set m_codebaseManager = New CodebaseManager' line to go except in global scope.