ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-02-03 17:50:41 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
corda/src/avian/machine.h

4074 lines
88 KiB
C
Raw Normal View History

update copyright years
2014-04-20 20:14:48 -06:00
/* Copyright (c) 2008-2014, Avian Contributors
prepend copyright notice and license to all source files; add license.txt and readme.txt
2008-02-19 11:06:52 -07:00
Permission to use, copy, modify, and/or distribute this software
for any purpose with or without fee is hereby granted, provided
that the above copyright notice and this permission notice appear
in all copies.
There is NO WARRANTY for this software. See license.txt for
details. */
more refactoring
2007-07-06 17:50:26 -06:00
#ifndef MACHINE_H
#define MACHINE_H
more JNI work
2007-06-24 19:34:07 -06:00
move headers from src to src/avian This is necessary to avoid name conflicts on various platforms. For example, iOS has its own util.h, and Windows has a process.h. By including our version as e.g. "avian/util.h", we avoid confusion with the system version.
2013-02-27 13:25:50 -07:00
#include "avian/common.h"
move java-specific declarations out of common.h
2013-02-20 22:14:18 -07:00
#include "java-common.h"
remove vm from code paths, to match namespacing
2014-02-07 14:24:56 -07:00
#include <avian/system/system.h>
break out signal handling from System
2014-02-21 17:06:17 -07:00
#include <avian/system/signal.h>
remove vm from code paths, to match namespacing
2014-02-07 14:24:56 -07:00
#include <avian/heap/heap.h>
generate accessors for array fields
2014-06-02 10:31:57 -06:00
#include <avian/util/slice.h>
move headers from src to src/avian This is necessary to avoid name conflicts on various platforms. For example, iOS has its own util.h, and Windows has a process.h. By including our version as e.g. "avian/util.h", we avoid confusion with the system version.
2013-02-27 13:25:50 -07:00
#include "avian/finder.h"
#include "avian/processor.h"
#include "avian/constants.h"
#include "avian/arch.h"
more JNI work
2007-06-24 19:34:07 -06:00
move abort.h to include, add namespacing
2013-02-19 22:42:07 -07:00
using namespace avian::util;
add support for building with MSVC on Windows
2009-08-26 18:26:44 -06:00
#ifdef PLATFORM_WINDOWS
more windows port fixes
2007-10-24 11:24:19 -06:00
# define JNICALL __stdcall
#else
# define JNICALL
#endif
more JNI work
2007-06-24 19:34:07 -06:00
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
#define PROTECT(thread, name) \
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
Thread::SingleProtector MAKE_NAME(protector_) (thread, &name);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
#define ACQUIRE(t, x) MonitorResource MAKE_NAME(monitorResource_) (t, x)
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
#define ACQUIRE_OBJECT(t, x) \
ObjectMonitorResource MAKE_NAME(monitorResource_) (t, x)
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
#define ACQUIRE_FIELD_FOR_READ(t, field) \
FieldReadResource MAKE_NAME(monitorResource_) (t, field)
#define ACQUIRE_FIELD_FOR_WRITE(t, field) \
fix cut-and-paste error in ACQUIRE_FIELD_FOR_WRITE definition
2011-04-10 14:42:46 -06:00
FieldWriteResource MAKE_NAME(monitorResource_) (t, field)
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
#define ACQUIRE_RAW(t, x) RawMonitorResource MAKE_NAME(monitorResource_) (t, x)
#define ENTER(t, state) StateResource MAKE_NAME(stateResource_) (t, state)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
#define THREAD_RESOURCE0(t, releaseBody) \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class MAKE_NAME(Resource_): public Thread::AutoResource { \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
public: \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
MAKE_NAME(Resource_)(Thread* t): AutoResource(t) { } \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
~MAKE_NAME(Resource_)() { releaseBody; } \
virtual void release() \
{ this->MAKE_NAME(Resource_)::~MAKE_NAME(Resource_)(); } \
} MAKE_NAME(resource_)(t);
#define OBJECT_RESOURCE(t, name, releaseBody) \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class MAKE_NAME(Resource_): public Thread::AutoResource { \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
public: \
MAKE_NAME(Resource_)(Thread* t, object name): \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t), name(name), protector(t, &(this->name)) { } \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
~MAKE_NAME(Resource_)() { releaseBody; } \
virtual void release() \
{ this->MAKE_NAME(Resource_)::~MAKE_NAME(Resource_)(); } \
\
private: \
object name; \
Thread::SingleProtector protector; \
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
} MAKE_NAME(resource_)(t, reinterpret_cast<object>(name));
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
#define THREAD_RESOURCE(t, type, name, releaseBody) \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class MAKE_NAME(Resource_): public Thread::AutoResource { \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
public: \
MAKE_NAME(Resource_)(Thread* t, type name): \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t), name(name) { } \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
~MAKE_NAME(Resource_)() { releaseBody; } \
virtual void release() \
{ this->MAKE_NAME(Resource_)::~MAKE_NAME(Resource_)(); } \
\
private: \
type name; \
} MAKE_NAME(resource_)(t, name);
#define THREAD_RESOURCE2(t, type1, name1, type2, name2, releaseBody) \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class MAKE_NAME(Resource_): public Thread::AutoResource { \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
public: \
MAKE_NAME(Resource_)(Thread* t, type1 name1, type2 name2): \
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t), name1(name1), name2(name2) { } \
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
~MAKE_NAME(Resource_)() { releaseBody; } \
virtual void release() \
{ this->MAKE_NAME(Resource_)::~MAKE_NAME(Resource_)(); } \
\
private: \
type1 name1; \
type2 name2; \
} MAKE_NAME(resource_)(t, name1, name2);
JNI up the wazoo
2007-06-24 20:02:24 -06:00
namespace vm {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
const bool Verbose = false;
classpath progress
2007-07-27 17:56:19 -06:00
const bool DebugRun = false;
more weak reference work, plus debug logging
2007-07-09 21:04:49 -06:00
const bool DebugStack = false;
bugfixes
2007-11-02 15:42:19 -06:00
const bool DebugMonitors = false;
preserve vm flags of bootstrap class (except for BootstrapFlag) in updateBootstrapClass()
2007-11-05 08:39:48 -07:00
const bool DebugReferences = false;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
fix unintentionally retained finalizables and improve low mem performance Objects which are eligable for finalization must be retained until after their finalize methods are called. However, the VM must determine the entire set of such objects before retaining any of them; otherwise the process of retaining a given object may cause others to become reachable and thus be considered ineligible for finalization even though they are only reachable via other finalizable objects. The end result of this mistake is that only a few of the objects which are finalizable will be recognized at each GC cycle, so it requires many such cycles to find them all, and if new objects become finalizable at a faster rate, the VM will never catch up and eventually run out of memory. This patch fixes the above mistake and also includes tuning to minimize the need for GC in low memory situations.
2013-03-07 20:17:05 -07:00
const bool AbortOnOutOfMemoryError = false;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
const uintptr_t HashTakenMark = 1;
const uintptr_t ExtendedMark = 2;
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
const uintptr_t FixedMark = 3;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
increase heap pool size and fixed footprint threshold constants based on performance profiling and experimentation
2008-11-22 14:47:18 -07:00
const unsigned ThreadHeapSizeInBytes = 64 * 1024;
const unsigned ThreadHeapSizeInWords = ThreadHeapSizeInBytes / BytesPerWord;
pre-allocate Thread::backupHeap for signal safety It's not safe to use malloc from a signal handler, so we can't allocate new memory when handling segfaults or Thread.getStackTrace signals. Instead, we allocate a fixed-size backup heap for each thread ahead of time and use it if there's no space left in the normal heap pool. In the rare case that the backup heap isn't large enough, we fall back to using a preallocated exception without a stack trace as a last resort.
2010-06-19 16:40:21 -06:00
const unsigned ThreadBackupHeapSizeInBytes = 2 * 1024;
const unsigned ThreadBackupHeapSizeInWords
= ThreadBackupHeapSizeInBytes / BytesPerWord;
increase heap pool size and fixed footprint threshold constants based on performance profiling and experimentation (second try)
2008-11-22 14:48:10 -07:00
const unsigned ThreadHeapPoolSize = 64;
increase heap pool size and fixed footprint threshold constants based on performance profiling and experimentation
2008-11-22 14:47:18 -07:00
const unsigned FixedFootprintThresholdInBytes
= ThreadHeapPoolSize * ThreadHeapSizeInBytes;
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
// number of zombie threads which may accumulate before we force a GC
// to clean them up:
const unsigned ZombieCollectionThreshold = 16;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
enum FieldCode {
VoidField,
ByteField,
CharField,
DoubleField,
FloatField,
IntField,
LongField,
ShortField,
BooleanField,
ObjectField
};
enum StackTag {
IntTag, // must be zero
ObjectTag
};
swap NativeLine and UnknownLine values to match Sun's convention
2011-03-17 09:41:23 -06:00
const int NativeLine = -2;
const int UnknownLine = -1;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
early sketch of continuation support
2009-05-03 14:57:11 -06:00
// class vmFlags:
finish java/lang/ref/* support; add wrapper classes for primitives
2007-07-19 21:18:25 -06:00
const unsigned ReferenceFlag = 1 << 0;
const unsigned WeakReferenceFlag = 1 << 1;
misc. bugfixes and tweaks
2007-07-28 10:10:13 -06:00
const unsigned NeedInitFlag = 1 << 2;
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
const unsigned InitFlag = 1 << 3;
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
const unsigned InitErrorFlag = 1 << 4;
const unsigned PrimitiveFlag = 1 << 5;
const unsigned BootstrapFlag = 1 << 6;
implement basic finalization support This implementation does not conform to the Java standard in that finalize methods are called from whichever thread happens to be garbage collecting, and that thread may hold locks, whereas the standard guarantees that finalize will be run from a thread which holds no locks. Also, an object will never be finalized more than once, even if its finalize method "rescues" (i.e. makes reachable) the object such that it might become unreachable a second time and thus a candidate for finalization once more. It's not clear to me from the standard if this is OK or not. Nonwithstanding the above, this implementation is useful for "normal" finalize methods which simply release resources associated with an object.
2009-07-21 18:57:55 -06:00
const unsigned HasFinalizerFlag = 1 << 7;
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
const unsigned LinkFlag = 1 << 8;
const unsigned HasFinalMemberFlag = 1 << 9;
const unsigned SingletonFlag = 1 << 10;
const unsigned ContinuationFlag = 1 << 11;
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
early sketch of continuation support
2009-05-03 14:57:11 -06:00
// method vmFlags:
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
const unsigned ClassInitFlag = 1 << 0;
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
const unsigned ConstructorFlag = 1 << 1;
finish java/lang/ref/* support; add wrapper classes for primitives
2007-07-19 21:18:25 -06:00
Implement dummy JNI GetVersion
2009-06-22 16:25:13 -06:00
#ifndef JNI_VERSION_1_6
#define JNI_VERSION_1_6 0x00010006
#endif
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
typedef Machine JavaVM;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
typedef Thread JNIEnv;
more JNI work
2007-06-24 19:34:07 -06:00
struct JNINativeMethod {
char* name;
char* signature;
void* function;
};
JNI up the wazoo
2007-06-24 20:02:24 -06:00
struct JavaVMVTable {
more JNI work
2007-06-24 19:34:07 -06:00
void* reserved0;
void* reserved1;
void* reserved2;
jint
(JNICALL *DestroyJavaVM)
(JavaVM*);
jint
(JNICALL *AttachCurrentThread)
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
(JavaVM*, JNIEnv**, void*);
more JNI work
2007-06-24 19:34:07 -06:00
jint
(JNICALL *DetachCurrentThread)
(JavaVM*);
jint
(JNICALL *GetEnv)
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
(JavaVM*, JNIEnv**, jint);
more JNI work
2007-06-24 19:34:07 -06:00
jint
(JNICALL *AttachCurrentThreadAsDaemon)
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
(JavaVM*, JNIEnv**, void*);
more JNI work
2007-06-24 19:34:07 -06:00
};
JNI up the wazoo
2007-06-24 20:02:24 -06:00
struct JNIEnvVTable {
more JNI work
2007-06-24 19:34:07 -06:00
void* reserved0;
void* reserved1;
void* reserved2;
void* reserved3;
jint
(JNICALL *GetVersion)
(JNIEnv*);
jclass
(JNICALL *DefineClass)
(JNIEnv*, const char*, jobject, const jbyte*, jsize);
jclass
(JNICALL *FindClass)
(JNIEnv*, const char*);
jmethodID
(JNICALL *FromReflectedMethod)
(JNIEnv*, jobject);
jfieldID
(JNICALL *FromReflectedField)
(JNIEnv*, jobject);
jobject
(JNICALL *ToReflectedMethod)
(JNIEnv*, jclass, jmethodID, jboolean);
jclass
(JNICALL *GetSuperclass)
(JNIEnv*, jclass);
jboolean
(JNICALL *IsAssignableFrom)
(JNIEnv*, jclass, jclass);
jobject
(JNICALL *ToReflectedField)
(JNIEnv*, jclass, jfieldID, jboolean);
jint
(JNICALL *Throw)
(JNIEnv*, jthrowable);
jint
(JNICALL *ThrowNew)
(JNIEnv*, jclass, const char*);
jthrowable
(JNICALL *ExceptionOccurred)
(JNIEnv*);
void
(JNICALL *ExceptionDescribe)
(JNIEnv*);
void
(JNICALL *ExceptionClear)
(JNIEnv*);
void
(JNICALL *FatalError)
(JNIEnv*, const char*);
jint
(JNICALL *PushLocalFrame)
(JNIEnv*, jint);
jobject
(JNICALL *PopLocalFrame)
(JNIEnv*, jobject);
jobject
(JNICALL *NewGlobalRef)
(JNIEnv*, jobject);
void
(JNICALL *DeleteGlobalRef)
(JNIEnv*, jobject);
void
(JNICALL *DeleteLocalRef)
(JNIEnv*, jobject);
jboolean
(JNICALL *IsSameObject)
(JNIEnv*, jobject, jobject);
jobject
(JNICALL *NewLocalRef)
(JNIEnv*, jobject);
jint
(JNICALL *EnsureLocalCapacity)
(JNIEnv*, jint);
jobject
(JNICALL *AllocObject)
(JNIEnv*, jclass);
jobject
(JNICALL *NewObject)
(JNIEnv*, jclass, jmethodID, ...);
jobject
(JNICALL *NewObjectV)
(JNIEnv*, jclass, jmethodID, va_list);
jobject
(JNICALL *NewObjectA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jclass
(JNICALL *GetObjectClass)
(JNIEnv*, jobject);
jboolean
(JNICALL *IsInstanceOf)
(JNIEnv*, jobject, jclass);
jmethodID
(JNICALL *GetMethodID)
(JNIEnv*, jclass, const char*, const char*);
jobject
(JNICALL *CallObjectMethod)
(JNIEnv*, jobject, jmethodID, ...);
jobject
(JNICALL *CallObjectMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jobject
(JNICALL *CallObjectMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jboolean
(JNICALL *CallBooleanMethod)
(JNIEnv*, jobject, jmethodID, ...);
jboolean
(JNICALL *CallBooleanMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jboolean
(JNICALL *CallBooleanMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jbyte
(JNICALL *CallByteMethod)
(JNIEnv*, jobject, jmethodID, ...);
jbyte
(JNICALL *CallByteMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jbyte
(JNICALL *CallByteMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jchar
(JNICALL *CallCharMethod)
(JNIEnv*, jobject, jmethodID, ...);
jchar
(JNICALL *CallCharMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jchar
(JNICALL *CallCharMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jshort
(JNICALL *CallShortMethod)
(JNIEnv*, jobject, jmethodID, ...);
jshort
(JNICALL *CallShortMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jshort
(JNICALL *CallShortMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jint
(JNICALL *CallIntMethod)
(JNIEnv*, jobject, jmethodID, ...);
jint
(JNICALL *CallIntMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jint
(JNICALL *CallIntMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jlong
(JNICALL *CallLongMethod)
(JNIEnv*, jobject, jmethodID, ...);
jlong
(JNICALL *CallLongMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jlong
(JNICALL *CallLongMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jfloat
(JNICALL *CallFloatMethod)
(JNIEnv*, jobject, jmethodID, ...);
jfloat
(JNICALL *CallFloatMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jfloat
(JNICALL *CallFloatMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jdouble
(JNICALL *CallDoubleMethod)
(JNIEnv*, jobject, jmethodID, ...);
jdouble
(JNICALL *CallDoubleMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
jdouble
(JNICALL *CallDoubleMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
void
(JNICALL *CallVoidMethod)
(JNIEnv*, jobject, jmethodID, ...);
void
(JNICALL *CallVoidMethodV)
(JNIEnv*, jobject, jmethodID, va_list);
void
(JNICALL *CallVoidMethodA)
(JNIEnv*, jobject, jmethodID, const jvalue*);
jobject
(JNICALL *CallNonvirtualObjectMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jobject
(JNICALL *CallNonvirtualObjectMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
jobject
(JNICALL *CallNonvirtualObjectMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jboolean
(JNICALL *CallNonvirtualBooleanMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jboolean
(JNICALL *CallNonvirtualBooleanMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
jboolean
(JNICALL *CallNonvirtualBooleanMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jbyte
(JNICALL *CallNonvirtualByteMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jbyte
(JNICALL *CallNonvirtualByteMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
jbyte
(JNICALL *CallNonvirtualByteMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jchar
(JNICALL *CallNonvirtualCharMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jchar
(JNICALL *CallNonvirtualCharMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
jchar
(JNICALL *CallNonvirtualCharMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jshort
(JNICALL *CallNonvirtualShortMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jshort
(JNICALL *CallNonvirtualShortMethodV)
(JNIEnv*, jobject, jclass, jmethodID,
va_list);
jshort
(JNICALL *CallNonvirtualShortMethodA)
(JNIEnv*, jobject, jclass, jmethodID,
const jvalue*);
jint
(JNICALL *CallNonvirtualIntMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jint
(JNICALL *CallNonvirtualIntMethodV)
(JNIEnv*, jobject, jclass, jmethodID,
va_list);
jint
(JNICALL *CallNonvirtualIntMethodA)
(JNIEnv*, jobject, jclass, jmethodID,
const jvalue*);
jlong
(JNICALL *CallNonvirtualLongMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jlong
(JNICALL *CallNonvirtualLongMethodV)
(JNIEnv*, jobject, jclass, jmethodID,
va_list);
jlong
(JNICALL *CallNonvirtualLongMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jfloat
(JNICALL *CallNonvirtualFloatMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jfloat
(JNICALL *CallNonvirtualFloatMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
jfloat
(JNICALL *CallNonvirtualFloatMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jdouble
(JNICALL *CallNonvirtualDoubleMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
jdouble
(JNICALL *CallNonvirtualDoubleMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
jdouble
(JNICALL *CallNonvirtualDoubleMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
void
(JNICALL *CallNonvirtualVoidMethod)
(JNIEnv*, jobject, jclass, jmethodID, ...);
void
(JNICALL *CallNonvirtualVoidMethodV)
(JNIEnv*, jobject, jclass, jmethodID, va_list);
void
(JNICALL *CallNonvirtualVoidMethodA)
(JNIEnv*, jobject, jclass, jmethodID, const jvalue*);
jfieldID
(JNICALL *GetFieldID)
(JNIEnv*, jclass, const char*, const char*);
jobject
(JNICALL *GetObjectField)
(JNIEnv*, jobject, jfieldID);
jboolean
(JNICALL *GetBooleanField)
(JNIEnv*, jobject, jfieldID);
jbyte
(JNICALL *GetByteField)
(JNIEnv*, jobject, jfieldID);
jchar
(JNICALL *GetCharField)
(JNIEnv*, jobject, jfieldID);
jshort
(JNICALL *GetShortField)
(JNIEnv*, jobject, jfieldID);
jint
(JNICALL *GetIntField)
(JNIEnv*, jobject, jfieldID);
jlong
(JNICALL *GetLongField)
(JNIEnv*, jobject, jfieldID);
jfloat
(JNICALL *GetFloatField)
(JNIEnv*, jobject, jfieldID);
jdouble
(JNICALL *GetDoubleField)
(JNIEnv*, jobject, jfieldID);
void
(JNICALL *SetObjectField)
(JNIEnv*, jobject, jfieldID, jobject);
void
(JNICALL *SetBooleanField)
(JNIEnv*, jobject, jfieldID, jboolean);
void
(JNICALL *SetByteField)
(JNIEnv*, jobject, jfieldID, jbyte);
void
(JNICALL *SetCharField)
(JNIEnv*, jobject, jfieldID, jchar);
void
(JNICALL *SetShortField)
(JNIEnv*, jobject, jfieldID, jshort);
void
(JNICALL *SetIntField)
(JNIEnv*, jobject, jfieldID, jint);
void
(JNICALL *SetLongField)
(JNIEnv*, jobject, jfieldID, jlong);
void
(JNICALL *SetFloatField)
(JNIEnv*, jobject, jfieldID, jfloat);
void
(JNICALL *SetDoubleField)
(JNIEnv*, jobject, jfieldID, jdouble);
jmethodID
(JNICALL *GetStaticMethodID)
(JNIEnv*, jclass, const char*, const char*);
jobject
(JNICALL *CallStaticObjectMethod)
(JNIEnv*, jclass, jmethodID, ...);
jobject
(JNICALL *CallStaticObjectMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jobject
(JNICALL *CallStaticObjectMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jboolean
(JNICALL *CallStaticBooleanMethod)
(JNIEnv*, jclass, jmethodID, ...);
jboolean
(JNICALL *CallStaticBooleanMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jboolean
(JNICALL *CallStaticBooleanMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jbyte
(JNICALL *CallStaticByteMethod)
(JNIEnv*, jclass, jmethodID, ...);
jbyte
(JNICALL *CallStaticByteMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jbyte
(JNICALL *CallStaticByteMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jchar
(JNICALL *CallStaticCharMethod)
(JNIEnv*, jclass, jmethodID, ...);
jchar
(JNICALL *CallStaticCharMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jchar
(JNICALL *CallStaticCharMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jshort
(JNICALL *CallStaticShortMethod)
(JNIEnv*, jclass, jmethodID, ...);
jshort
(JNICALL *CallStaticShortMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jshort
(JNICALL *CallStaticShortMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jint
(JNICALL *CallStaticIntMethod)
(JNIEnv*, jclass, jmethodID, ...);
jint
(JNICALL *CallStaticIntMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jint
(JNICALL *CallStaticIntMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jlong
(JNICALL *CallStaticLongMethod)
(JNIEnv*, jclass, jmethodID, ...);
jlong
(JNICALL *CallStaticLongMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jlong
(JNICALL *CallStaticLongMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jfloat
(JNICALL *CallStaticFloatMethod)
(JNIEnv*, jclass, jmethodID, ...);
jfloat
(JNICALL *CallStaticFloatMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jfloat
(JNICALL *CallStaticFloatMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jdouble
(JNICALL *CallStaticDoubleMethod)
(JNIEnv*, jclass, jmethodID, ...);
jdouble
(JNICALL *CallStaticDoubleMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
jdouble
(JNICALL *CallStaticDoubleMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
void
(JNICALL *CallStaticVoidMethod)
(JNIEnv*, jclass, jmethodID, ...);
void
(JNICALL *CallStaticVoidMethodV)
(JNIEnv*, jclass, jmethodID, va_list);
void
(JNICALL *CallStaticVoidMethodA)
(JNIEnv*, jclass, jmethodID, const jvalue*);
jfieldID
(JNICALL *GetStaticFieldID)
(JNIEnv*, jclass, const char*, const char*);
jobject
(JNICALL *GetStaticObjectField)
(JNIEnv*, jclass, jfieldID);
jboolean
(JNICALL *GetStaticBooleanField)
(JNIEnv*, jclass, jfieldID);
jbyte
(JNICALL *GetStaticByteField)
(JNIEnv*, jclass, jfieldID);
jchar
(JNICALL *GetStaticCharField)
(JNIEnv*, jclass, jfieldID);
jshort
(JNICALL *GetStaticShortField)
(JNIEnv*, jclass, jfieldID);
jint
(JNICALL *GetStaticIntField)
(JNIEnv*, jclass, jfieldID);
jlong
(JNICALL *GetStaticLongField)
(JNIEnv*, jclass, jfieldID);
jfloat
(JNICALL *GetStaticFloatField)
(JNIEnv*, jclass, jfieldID);
jdouble
(JNICALL *GetStaticDoubleField)
(JNIEnv*, jclass, jfieldID);
void
(JNICALL *SetStaticObjectField)
(JNIEnv*, jclass, jfieldID, jobject);
void
(JNICALL *SetStaticBooleanField)
(JNIEnv*, jclass, jfieldID, jboolean);
void
(JNICALL *SetStaticByteField)
(JNIEnv*, jclass, jfieldID, jbyte);
void
(JNICALL *SetStaticCharField)
(JNIEnv*, jclass, jfieldID, jchar);
void
(JNICALL *SetStaticShortField)
(JNIEnv*, jclass, jfieldID, jshort);
void
(JNICALL *SetStaticIntField)
(JNIEnv*, jclass, jfieldID, jint);
void
(JNICALL *SetStaticLongField)
(JNIEnv*, jclass, jfieldID, jlong);
void
(JNICALL *SetStaticFloatField)
(JNIEnv*, jclass, jfieldID, jfloat);
void
(JNICALL *SetStaticDoubleField)
(JNIEnv*, jclass, jfieldID, jdouble);
jstring
(JNICALL *NewString)
(JNIEnv*, const jchar*, jsize);
jsize
(JNICALL *GetStringLength)
(JNIEnv*, jstring);
const jchar*
(JNICALL *GetStringChars)
(JNIEnv*, jstring, jboolean*);
void
(JNICALL *ReleaseStringChars)
(JNIEnv*, jstring, const jchar*);
jstring
(JNICALL *NewStringUTF)
(JNIEnv*, const char*);
jsize
(JNICALL *GetStringUTFLength)
(JNIEnv*, jstring);
const char*
(JNICALL *GetStringUTFChars)
(JNIEnv*, jstring, jboolean*);
void
(JNICALL *ReleaseStringUTFChars)
(JNIEnv*, jstring, const char*);
jsize
(JNICALL *GetArrayLength)
(JNIEnv*, jarray);
jobjectArray
(JNICALL *NewObjectArray)
(JNIEnv*, jsize, jclass, jobject);
jobject
(JNICALL *GetObjectArrayElement)
(JNIEnv*, jobjectArray, jsize);
void
(JNICALL *SetObjectArrayElement)
(JNIEnv*, jobjectArray, jsize, jobject);
jbooleanArray
(JNICALL *NewBooleanArray)
(JNIEnv*, jsize);
jbyteArray
(JNICALL *NewByteArray)
(JNIEnv*, jsize);
jcharArray
(JNICALL *NewCharArray)
(JNIEnv*, jsize);
jshortArray
(JNICALL *NewShortArray)
(JNIEnv*, jsize);
jintArray
(JNICALL *NewIntArray)
(JNIEnv*, jsize);
jlongArray
(JNICALL *NewLongArray)
(JNIEnv*, jsize);
jfloatArray
(JNICALL *NewFloatArray)
(JNIEnv*, jsize);
jdoubleArray
(JNICALL *NewDoubleArray)
(JNIEnv*, jsize);
jboolean*
(JNICALL *GetBooleanArrayElements)
(JNIEnv*, jbooleanArray, jboolean*);
jbyte*
(JNICALL *GetByteArrayElements)
(JNIEnv*, jbyteArray, jboolean*);
jchar*
(JNICALL *GetCharArrayElements)
(JNIEnv*, jcharArray, jboolean*);
jshort*
(JNICALL *GetShortArrayElements)
(JNIEnv*, jshortArray, jboolean*);
jint*
(JNICALL *GetIntArrayElements)
(JNIEnv*, jintArray, jboolean*);
jlong*
(JNICALL *GetLongArrayElements)
(JNIEnv*, jlongArray, jboolean*);
jfloat*
(JNICALL *GetFloatArrayElements)
(JNIEnv*, jfloatArray, jboolean*);
jdouble*
(JNICALL *GetDoubleArrayElements)
(JNIEnv*, jdoubleArray, jboolean*);
void
(JNICALL *ReleaseBooleanArrayElements)
(JNIEnv*, jbooleanArray, jboolean*, jint);
void
(JNICALL *ReleaseByteArrayElements)
(JNIEnv*, jbyteArray, jbyte*, jint);
void
(JNICALL *ReleaseCharArrayElements)
(JNIEnv*, jcharArray, jchar*, jint);
void
(JNICALL *ReleaseShortArrayElements)
(JNIEnv*, jshortArray, jshort*, jint);
void
(JNICALL *ReleaseIntArrayElements)
(JNIEnv*, jintArray, jint*, jint);
void
(JNICALL *ReleaseLongArrayElements)
(JNIEnv*, jlongArray, jlong*, jint);
void
(JNICALL *ReleaseFloatArrayElements)
(JNIEnv*, jfloatArray, jfloat*, jint);
void
(JNICALL *ReleaseDoubleArrayElements)
(JNIEnv*, jdoubleArray, jdouble*, jint);
void
(JNICALL *GetBooleanArrayRegion)
(JNIEnv*, jbooleanArray, jsize, jsize, jboolean*);
void
(JNICALL *GetByteArrayRegion)
(JNIEnv*, jbyteArray, jsize, jsize, jbyte*);
void
(JNICALL *GetCharArrayRegion)
(JNIEnv*, jcharArray, jsize, jsize, jchar*);
void
(JNICALL *GetShortArrayRegion)
(JNIEnv*, jshortArray, jsize, jsize, jshort*);
void
(JNICALL *GetIntArrayRegion)
(JNIEnv*, jintArray, jsize, jsize, jint*);
void
(JNICALL *GetLongArrayRegion)
(JNIEnv*, jlongArray, jsize, jsize, jlong*);
void
(JNICALL *GetFloatArrayRegion)
(JNIEnv*, jfloatArray, jsize, jsize, jfloat*);
void
(JNICALL *GetDoubleArrayRegion)
(JNIEnv*, jdoubleArray, jsize, jsize, jdouble*);
void
(JNICALL *SetBooleanArrayRegion)
(JNIEnv*, jbooleanArray, jsize, jsize, const jboolean*);
void
(JNICALL *SetByteArrayRegion)
(JNIEnv*, jbyteArray, jsize, jsize, const jbyte*);
void
(JNICALL *SetCharArrayRegion)
(JNIEnv*, jcharArray, jsize, jsize, const jchar*);
void
(JNICALL *SetShortArrayRegion)
(JNIEnv*, jshortArray, jsize, jsize, const jshort*);
void
(JNICALL *SetIntArrayRegion)
(JNIEnv*, jintArray, jsize, jsize, const jint*);
void
(JNICALL *SetLongArrayRegion)
(JNIEnv*, jlongArray, jsize, jsize, const jlong*);
void
(JNICALL *SetFloatArrayRegion)
(JNIEnv*, jfloatArray, jsize, jsize, const jfloat*);
void
(JNICALL *SetDoubleArrayRegion)
(JNIEnv*, jdoubleArray, jsize, jsize, const jdouble*);
jint
(JNICALL *RegisterNatives)
(JNIEnv*, jclass, const JNINativeMethod*, jint);
jint
(JNICALL *UnregisterNatives)
(JNIEnv*, jclass);
jint
(JNICALL *MonitorEnter)
(JNIEnv*, jobject);
jint
(JNICALL *MonitorExit)
(JNIEnv*, jobject);
jint
(JNICALL *GetJavaVM)
(JNIEnv*, JavaVM**);
void
(JNICALL *GetStringRegion)
(JNIEnv*, jstring, jsize, jsize, jchar*);
void
(JNICALL *GetStringUTFRegion)
(JNIEnv*, jstring, jsize, jsize, char*);
void*
(JNICALL *GetPrimitiveArrayCritical)
(JNIEnv*, jarray, jboolean*);
void
(JNICALL *ReleasePrimitiveArrayCritical)
(JNIEnv*, jarray, void*, jint);
const jchar*
(JNICALL *GetStringCritical)
(JNIEnv*, jstring, jboolean*);
void
(JNICALL *ReleaseStringCritical)
(JNIEnv*, jstring, const jchar*);
jweak
(JNICALL *NewWeakGlobalRef)
(JNIEnv*, jobject);
void
(JNICALL *DeleteWeakGlobalRef)
(JNIEnv*, jweak);
jboolean
(JNICALL *ExceptionCheck)
(JNIEnv*);
jobject
(JNICALL *NewDirectByteBuffer)
(JNIEnv*, void*, jlong);
void*
(JNICALL *GetDirectBufferAddress)
(JNIEnv* env, jobject);
jlong
(JNICALL *GetDirectBufferCapacity)
(JNIEnv*, jobject);
hello, world!
2008-06-15 14:17:52 -06:00
more JNI work
2007-06-24 19:34:07 -06:00
};
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
inline void
atomicOr(uint32_t* p, int v)
{
for (uint32_t old = *p;
not atomicCompareAndSwap32(p, old, old | v);
old = *p)
{ }
}
inline void
atomicAnd(uint32_t* p, int v)
{
for (uint32_t old = *p;
not atomicCompareAndSwap32(p, old, old & v);
old = *p)
{ }
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
inline int
strcmp(const int8_t* a, const int8_t* b)
{
return ::strcmp(reinterpret_cast<const char*>(a),
reinterpret_cast<const char*>(b));
}
sketch of finalizer/weak reference overhaul; type generator bugfixes involving array member layout
2007-07-09 19:43:43 -06:00
void
noop();
more JNIEnvVTable entries
2007-09-07 17:20:21 -06:00
class Reference {
public:
implement JNI methods NewWeakGlobalRef and DeleteWeakGlobalRef
2012-02-29 11:51:30 -07:00
Reference(object target, Reference** handle, bool weak):
more JNIEnvVTable entries
2007-09-07 17:20:21 -06:00
target(target),
implement Processor::makeLocalReference()/disposeLocalReference()
2007-09-29 21:33:38 -06:00
next(*handle),
reuse JNI references when possible Before allocating a new reference in NewGlobalReference or when creating a local reference, we look for a previously-allocated reference pointing to the same object. This is a linear search, but usually the number of elements in the reference list is small, whereas the memory, locking, and allocation overhead of creating duplicate references can be large.
2009-12-16 19:16:51 -07:00
handle(handle),
implement JNI methods NewWeakGlobalRef and DeleteWeakGlobalRef
2012-02-29 11:51:30 -07:00
count(0),
weak(weak)
implement Processor::makeLocalReference()/disposeLocalReference()
2007-09-29 21:33:38 -06:00
{
if (next) {
next->handle = &next;
}
*handle = this;
}
more JNIEnvVTable entries
2007-09-07 17:20:21 -06:00
object target;
Reference* next;
implement Processor::makeLocalReference()/disposeLocalReference()
2007-09-29 21:33:38 -06:00
Reference** handle;
reuse JNI references when possible Before allocating a new reference in NewGlobalReference or when creating a local reference, we look for a previously-allocated reference pointing to the same object. This is a linear search, but usually the number of elements in the reference list is small, whereas the memory, locking, and allocation overhead of creating duplicate references can be large.
2009-12-16 19:16:51 -07:00
unsigned count;
implement JNI methods NewWeakGlobalRef and DeleteWeakGlobalRef
2012-02-29 11:51:30 -07:00
bool weak;
more JNIEnvVTable entries
2007-09-07 17:20:21 -06:00
};
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
class Classpath;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
class Gc {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
public:
bugfixes
2007-09-12 21:15:16 -06:00
enum Type {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
#include "type-enums.cpp"
bugfixes
2007-09-12 21:15:16 -06:00
};
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
};
class GcObject {
public:
template <class T>
T* as(Thread* t);
template <class T>
bool isa(Thread* t);
protected:
template <class T>
T& field_at(size_t offset)
{
return *reinterpret_cast<T*>(reinterpret_cast<uint8_t*>(this) + offset);
}
};
class GcFinalizer;
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
class GcClassLoader;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
class Machine {
public:
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
refactor memory management code We now support immortal objects, which the GC will scan for references but not consider for collection. On x86_64, we allocate JIT code memory via mmap, which lets us map memory into the bottom 2GB of the address space, ensuring that 32-bit relative jumps and calls work.
2008-01-09 18:20:36 -07:00
enum AllocationType {
MovableAllocation,
FixedAllocation,
ImmortalAllocation
fix use of uninitialized values at root thread creation time when running in stress mode; allocate Thread::defaultHeap on the heap instead of as part of the Thread structure
2007-10-13 19:18:25 -06:00
};
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
enum Root {
BootLoader,
AppLoader,
BootstrapClassMap,
make JVM_GetSystemPackage a bit smarter The original stub implementation just echoed back its argument, but that confused URLClassLoader when dealing with sealed JARs -- returning a non-null value for a non-system class from JVM_GetSystemPackage made URLClassloader think it had already loaded a class from a package which was supposed to be sealed, resulting in SecurityExceptions which ultimately triggered NoClassDefFoundErrors. The solution is to only return non-null values for actual system classes.
2012-09-24 17:43:34 -06:00
PackageMap,
fix various classloading deadlocks and races
2010-09-22 13:58:46 -06:00
FindLoadedClassMethod,
LoadClassMethod,
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
MonitorMap,
StringMap,
ByteArrayMap,
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
PoolMap,
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
ClassRuntimeDataTable,
MethodRuntimeDataTable,
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
JNIMethodTable,
handle volatile fields properly in JNI Get/Set methods This commit ensures that we use the proper memory barriers or locking necessary to preserve volatile semantics for such fields when accessed or updated via JNI.
2011-03-15 19:34:00 -06:00
JNIFieldTable,
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
ShutdownHooks,
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
FinalizerThread,
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
ObjectsToFinalize,
avoid calling doCollect recursively We must not allocate heap objects from doCollect, since it might trigger a GC while one is already in progress, which can cause trouble when we're still queuing up objects to finalize, among other things. To avoid this, I've added extra fields to the finalizer and cleaner types which we can use to link instances up during GC without allocating new memory.
2011-03-25 19:11:38 -06:00
ObjectsToClean,
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
NullPointerException,
throw ArithmeticException on divide-by-zero
2010-12-19 17:47:21 -07:00
ArithmeticException,
add support for accessing embedded JARs as if they were directories This allows OpenJDK to access time zone data which is normally found under java.home, but which we must embed in the executable itself to create a self-contained build. The VM intercepts various file operations, looking for paths which start with a prefix specified by the avian.embed.prefix property and redirecting those operations to an embedded JAR. For example, if avian.embed.prefix is "/avian-embedded", and code calls File.exists() with a path of "/avian-embedded/javahomeJar/foo.txt", the VM looks for a function named javahomeJar via dlsym, calls the function to find the memory region containing the embeded JAR, and finally consults the JAR to see if the file "foo.txt" exists.
2010-11-05 13:18:28 -06:00
ArrayIndexOutOfBoundsException,
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
OutOfMemoryError,
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
Shutdown,
add support for accessing embedded JARs as if they were directories This allows OpenJDK to access time zone data which is normally found under java.home, but which we must embed in the executable itself to create a self-contained build. The VM intercepts various file operations, looking for paths which start with a prefix specified by the avian.embed.prefix property and redirecting those operations to an embedded JAR. For example, if avian.embed.prefix is "/avian-embedded", and code calls File.exists() with a path of "/avian-embedded/javahomeJar/foo.txt", the VM looks for a function named javahomeJar via dlsym, calls the function to find the memory region containing the embeded JAR, and finally consults the JAR to see if the file "foo.txt" exists.
2010-11-05 13:18:28 -06:00
VirtualFileFinders,
more Android class library work
2013-02-21 15:37:17 -07:00
VirtualFiles,
remove thread from thread group on termination In the OpenJDK library, ThreadGroup maintains an array of all Threads in that group, so the VM must explicitly remove threads as they exit or else neither they nor any objects they reference will be eligable for GC.
2013-03-05 09:06:19 -07:00
ArrayInterfaceTable,
ThreadTerminated
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
};
remove thread from thread group on termination In the OpenJDK library, ThreadGroup maintains an array of all Threads in that group, so the VM must explicitly remove threads as they exit or else neither they nor any objects they reference will be eligable for GC.
2013-03-05 09:06:19 -07:00
static const unsigned RootCount = ThreadTerminated + 1;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
Machine(System* system, Heap* heap, Finder* bootFinder, Finder* appFinder,
Processor* processor, Classpath* classpath, const char** properties,
enable JMX support for openjdk-src build and implement GetInputArgumentArray
2011-08-05 18:06:29 -06:00
unsigned propertyCount, const char** arguments,
implement -Xss command line option
2012-03-14 12:36:42 -06:00
unsigned argumentCount, unsigned stackSizeInBytes);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
~Machine() {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
dispose();
}
void dispose();
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
JavaVMVTable* vtable;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
System* system;
refactor memory allocation to allow better detection and handling of low-memory conditions
2008-01-13 15:05:08 -07:00
Heap::Client* heapClient;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
Heap* heap;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
Finder* bootFinder;
Finder* appFinder;
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
Processor* processor;
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
Classpath* classpath;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
Thread* rootThread;
Thread* exclusive;
run java finalizers in a separate thread to guarantee no application locks are held when doing so
2009-08-24 17:51:31 -06:00
Thread* finalizeThread;
more JNIEnvVTable entries
2007-09-07 17:20:21 -06:00
Reference* jniReferences;
Trying to solve the properties memory problem
2014-04-09 10:16:53 +04:00
char** properties;
Merge branch 'master' into powerpc Conflicts: makefile src/assembler.h src/compile.cpp src/compiler.cpp src/compiler.h src/finder.cpp
2008-11-11 08:20:49 -07:00
unsigned propertyCount;
enable JMX support for openjdk-src build and implement GetInputArgumentArray
2011-08-05 18:06:29 -06:00
const char** arguments;
unsigned argumentCount;
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
unsigned threadCount;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
unsigned activeCount;
unsigned liveCount;
implement Runtime.addShutdownHook and Thread.setDaemon; avoid segfaults due to an application calling e.g. CallStaticBooleanMethod when it really meant CallStaticVoidMethod
2009-08-19 14:27:03 -06:00
unsigned daemonCount;
move fixed object (mark and sweep) support into heap.cpp and refine algorithms for determining when and how much to GC
2007-10-28 13:14:53 -06:00
unsigned fixedFootprint;
implement -Xss command line option
2012-03-14 12:36:42 -06:00
unsigned stackSizeInBytes;
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
System::Local* localThread;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
System::Monitor* stateLock;
System::Monitor* heapLock;
System::Monitor* classLock;
finish java/lang/ref/* support; add wrapper classes for primitives
2007-07-19 21:18:25 -06:00
System::Monitor* referenceLock;
implement Runtime.addShutdownHook and Thread.setDaemon; avoid segfaults due to an application calling e.g. CallStaticBooleanMethod when it really meant CallStaticVoidMethod
2009-08-19 14:27:03 -06:00
System::Monitor* shutdownLock;
remove Machine::lastLibrary and rename firstLibrary to libraries
2008-01-29 08:19:15 -07:00
System::Library* libraries;
add optional avian.error.log system property This property may be used to specify a file name to use for printing stack traces for unhandled exceptions. The default is stderr.
2011-03-15 17:27:17 -06:00
FILE* errorLog;
add optional LZMA support for compressing embedded JARs, boot images, and shared objects
2012-06-02 09:06:22 -06:00
BootImage* bootimage;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
object types;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
object roots;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcFinalizer* finalizers;
GcFinalizer* tenuredFinalizers;
sketch of finalizer/weak reference overhaul; type generator bugfixes involving array member layout
2007-07-09 19:43:43 -06:00
object finalizeQueue;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
object weakReferences;
sketch of finalizer/weak reference overhaul; type generator bugfixes involving array member layout
2007-07-09 19:43:43 -06:00
object tenuredWeakReferences;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
bool unsafe;
avoid calling doCollect recursively We must not allocate heap objects from doCollect, since it might trigger a GC while one is already in progress, which can cause trouble when we're still queuing up objects to finalize, among other things. To avoid this, I've added extra fields to the finalizer and cleaner types which we can use to link instances up during GC without allocating new memory.
2011-03-25 19:11:38 -06:00
bool collecting;
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
bool triedBuiltinOnLoad;
remove unused Heap::Client::outOfMemory method The heap-dump-on-OOM feature has been moved to the collect function.
2011-02-02 08:46:20 -07:00
bool dumpedHeapOnOOM;
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
bool alive;
JNIEnv and JavaVM method implementations
2007-09-10 17:33:58 -06:00
JavaVMVTable javaVMVTable;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
JNIEnvVTable jniEnvVTable;
increase heap pool size and fixed footprint threshold constants based on performance profiling and experimentation
2008-11-22 14:47:18 -07:00
uintptr_t* heapPool[ThreadHeapPoolSize];
add Machine::heapPool, allowing threads to acquire replacement heaps up to a point before forcing a GC
2007-08-22 08:50:29 -06:00
unsigned heapPoolIndex;
add optional LZMA support for compressing embedded JARs, boot images, and shared objects
2012-06-02 09:06:22 -06:00
unsigned bootimageSize;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
};
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
void
printTrace(Thread* t, object exception);
uint8_t&
threadInterrupted(Thread* t, object thread);
fix a few threading bugs in windows port
2007-10-23 16:21:28 -06:00
void
enterActiveState(Thread* t);
refactor memory allocation to allow better detection and handling of low-memory conditions
2008-01-13 15:05:08 -07:00
#ifdef VM_STRESS
inline void stress(Thread* t);
#else // not VM_STRESS
#define stress(t)
#endif // not VM_STRESS
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
uint64_t
runThread(Thread*, uintptr_t*);
use virtual dispatch when calling Thread.run from VM
2008-06-25 10:28:11 -06:00
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
uint64_t
run(Thread* t, uint64_t (*function)(Thread*, uintptr_t*),
uintptr_t* arguments);
run java finalizers in a separate thread to guarantee no application locks are held when doing so
2009-08-24 17:51:31 -06:00
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
void
checkDaemon(Thread* t);
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
object&
root(Thread* t, Machine::Root root);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
extern "C" uint64_t
vmRun(uint64_t (*function)(Thread*, uintptr_t*), uintptr_t* arguments,
void* checkpoint);
extern "C" void
vmRun_returnAddress();
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
class Thread {
public:
enum State {
NoState,
ActiveState,
IdleState,
ZombieState,
more GC stress fixes
2007-07-17 19:33:00 -06:00
JoinedState,
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
ExclusiveState,
ExitState
};
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
static const unsigned UseBackupHeapFlag = 1 << 0;
static const unsigned WaitingFlag = 1 << 1;
static const unsigned TracingFlag = 1 << 2;
static const unsigned DaemonFlag = 1 << 3;
static const unsigned StressFlag = 1 << 4;
static const unsigned ActiveFlag = 1 << 5;
fix race condition in interrupting/joining threads as they are exiting My recent commit to ensure that OS resources are released immediately upon thread exit introduced a race condition where interrupting or joining a thread as it exited could lead to attempts to use already-released resources. This commit adds locking to avoid the race.
2010-11-16 10:50:19 -07:00
static const unsigned SystemFlag = 1 << 6;
avoid running out of OS resources due to zombie thread accumulation (part 2) My previous attempt wasn't quite sufficient, since it was too late to call join on a thread which had already exited given the code was written to aggressively dispose of system handles as soon as the thread exited. The solution is to delay disposing these handles until after we're able to join the thread.
2012-02-03 17:20:20 -07:00
static const unsigned JoinFlag = 1 << 7;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
class Protector {
public:
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
Protector(Thread* t): t(t), next(t->protector) {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
t->protector = this;
}
Merge branch 'master' into powerpc Conflicts: makefile src/assembler.h src/compile.cpp src/compiler.cpp src/compiler.h src/finder.cpp
2008-11-11 08:20:49 -07:00
~Protector() {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
t->protector = next;
}
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
virtual void visit(Heap::Visitor* v) = 0;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
Thread* t;
Protector* next;
};
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
class SingleProtector: public Protector {
public:
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
SingleProtector(Thread* t, void* p): Protector(t), p(p) { }
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
virtual void visit(Heap::Visitor* v) {
move fixed object (mark and sweep) support into heap.cpp and refine algorithms for determining when and how much to GC
2007-10-28 13:14:53 -06:00
v->visit(p);
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
void* p;
JIT GC progress; fix interface method lookup bug
2007-10-12 11:56:43 -06:00
};
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
class Resource {
public:
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
Resource(Thread* t, Resource* next): t(t), next(next) {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
t->resource = this;
}
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
virtual void release() = 0;
Thread* t;
Resource* next;
};
class AutoResource: public Resource {
public:
AutoResource(Thread* t): Resource(t, t->resource) { }
~AutoResource() {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
t->resource = next;
}
virtual void release() = 0;
};
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class ClassInitStack: public AutoResource {
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
public:
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
ClassInitStack(Thread* t, GcClass* class_):
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t),
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
next(t->classInitStack),
class_(class_),
protector(t, &(this->class_))
{
t->classInitStack = this;
}
~ClassInitStack() {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
t->classInitStack = next;
}
virtual void release() {
this->ClassInitStack::~ClassInitStack();
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
}
ClassInitStack* next;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass* class_;
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
SingleProtector protector;
};
fix case of JNIEnv::FindClass called from JNI_OnLoad If an JNI_OnLoad implementation calls FindClass when using the OpenJDK class library, the calling method on the Java stack will be ClassLoader.loadLibrary. However, we must use the class loader of the class attempting to load the library in this case, not the system classloader. Therefore, we now maintain a stack such that the latest class to load a library in the current thread is at the top, and we use that class whenever FindClass is called by ClassLoader.loadLibrary (via JNI_OnLoad). Note that this patch does not attempt to address the same problem for the Avian or Android class libraries, but the same strategy should work for them as well.
2014-06-23 17:17:13 -06:00
class LibraryLoadStack: public AutoResource {
public:
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
LibraryLoadStack(Thread* t, GcClassLoader* classLoader)
fix JNIEnv::FindClass calls from JNI_OnLoad for all supported class libraries This also fixes the some Android build rot and updates the version of OpenSSL used.
2014-07-01 10:18:45 -06:00
: AutoResource(t),
next(t->libraryLoadStack),
classLoader(classLoader),
protector(t, &(this->classLoader))
fix case of JNIEnv::FindClass called from JNI_OnLoad If an JNI_OnLoad implementation calls FindClass when using the OpenJDK class library, the calling method on the Java stack will be ClassLoader.loadLibrary. However, we must use the class loader of the class attempting to load the library in this case, not the system classloader. Therefore, we now maintain a stack such that the latest class to load a library in the current thread is at the top, and we use that class whenever FindClass is called by ClassLoader.loadLibrary (via JNI_OnLoad). Note that this patch does not attempt to address the same problem for the Avian or Android class libraries, but the same strategy should work for them as well.
2014-06-23 17:17:13 -06:00
{
t->libraryLoadStack = this;
}
~LibraryLoadStack() {
t->libraryLoadStack = next;
}
virtual void release() {
this->LibraryLoadStack::~LibraryLoadStack();
}
LibraryLoadStack* next;
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
GcClassLoader* classLoader;
fix case of JNIEnv::FindClass called from JNI_OnLoad If an JNI_OnLoad implementation calls FindClass when using the OpenJDK class library, the calling method on the Java stack will be ClassLoader.loadLibrary. However, we must use the class loader of the class attempting to load the library in this case, not the system classloader. Therefore, we now maintain a stack such that the latest class to load a library in the current thread is at the top, and we use that class whenever FindClass is called by ClassLoader.loadLibrary (via JNI_OnLoad). Note that this patch does not attempt to address the same problem for the Avian or Android class libraries, but the same strategy should work for them as well.
2014-06-23 17:17:13 -06:00
SingleProtector protector;
};
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
class Checkpoint {
public:
Checkpoint(Thread* t):
t(t),
next(t->checkpoint),
resource(t->resource),
protector(t->protector),
noThrow(false)
{
t->checkpoint = this;
}
~Checkpoint() {
t->checkpoint = next;
}
virtual void NO_RETURN unwind() = 0;
Thread* t;
Checkpoint* next;
Resource* resource;
Protector* protector;
bool noThrow;
};
class RunCheckpoint: public Checkpoint {
public:
RunCheckpoint(Thread* t):
Checkpoint(t),
support stack unwinding without using a frame pointer Previously, we unwound the stack by following the chain of frame pointers for normal returns, stack trace creation, and exception unwinding. On x86, this required reserving EBP/RBP for frame pointer duties, making it unavailable for general computation and requiring that it be explicitly saved and restored on entry and exit, respectively. On PowerPC, we use an ABI that makes the stack pointer double as a frame pointer, so it doesn't cost us anything. We've been using the same convention on ARM, but it doesn't match the native calling convention, which makes it unusable when we want to call native code from Java and pass arguments on the stack. So far, the ARM calling convention mismatch hasn't been an issue because we've never passed more arguments from Java to native code than would fit in registers. However, we must now pass an extra argument (the thread pointer) to e.g. divideLong so it can throw an exception on divide by zero, which means the last argument must be passed on the stack. This will clobber the linkage area we've been using to hold the frame pointer, so we need to stop using it. One solution would be to use the same convention on ARM as we do on x86, but this would introduce the same overhead of making a register unavailable for general use and extra code at method entry and exit. Instead, this commit removes the need for a frame pointer. Unwinding involves consulting a map of instruction offsets to frame sizes which is generated at compile time. This is necessary because stack trace creation can happen at any time due to Thread.getStackTrace being called by another thread, and the frame size varies during the execution of a method. So far, only x86(_64) is working, and continuations and tail call optimization are probably broken. More to come.
2011-01-16 19:05:05 -07:00
stack(0)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{ }
virtual void unwind() {
void* stack = this->stack;
this->stack = 0;
expect(t->m->system, stack);
enable use-frame-pointer=true build Also, include Continuations, Coroutines, and DynamicWind tests in test suite for continuations=true build.
2011-01-27 21:06:01 -07:00
vmJump(voidPointer(vmRun_returnAddress), 0, stack, t, 0, 0);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
}
void* stack;
};
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
class Runnable: public System::Runnable {
public:
Runnable(Thread* t): t(t) { }
virtual void attach(System::Thread* st) {
t->systemThread = st;
}
virtual void run() {
fix a few threading bugs in windows port
2007-10-23 16:21:28 -06:00
enterActiveState(t);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
vm::run(t, runThread, 0);
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
if (t->exception and t->exception != root(t, Machine::Shutdown)) {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
printTrace(t, t->exception);
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
}
t->exit();
}
virtual bool interrupted() {
return false if javaThread is null in Thread::Runnable::interrupted This field may be null if the thread is in the process of being attached to the VM.
2011-02-15 21:44:27 -07:00
return t->javaThread and threadInterrupted(t, t->javaThread);
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
}
virtual void setInterrupted(bool v) {
threadInterrupted(t, t->javaThread) = v;
}
Thread* t;
};
start work on reflection; bugfixes
2007-07-23 19:44:20 -06:00
Thread(Machine* m, object javaThread, Thread* parent);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
support classloading from jar files compiled into the executable
2007-10-25 16:06:05 -06:00
void init();
progress on thread support
2007-07-07 12:09:16 -06:00
void exit();
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
void dispose();
JNIEnvVTable* vtable;
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
Machine* m;
progress on thread support
2007-07-07 12:09:16 -06:00
Thread* parent;
Thread* peer;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
Thread* child;
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
Thread* waitNext;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
State state;
more JNIEnvVTable entries
2007-09-07 17:20:21 -06:00
unsigned criticalLevel;
progress on thread support
2007-07-07 12:09:16 -06:00
System::Thread* systemThread;
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
System::Monitor* lock;
progress on thread support
2007-07-07 12:09:16 -06:00
object javaThread;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
object exception;
unsigned heapIndex;
fix bug in calculating GC footprint in new heap pool code
2007-08-22 20:24:25 -06:00
unsigned heapOffset;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
Protector* protector;
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
ClassInitStack* classInitStack;
fix case of JNIEnv::FindClass called from JNI_OnLoad If an JNI_OnLoad implementation calls FindClass when using the OpenJDK class library, the calling method on the Java stack will be ClassLoader.loadLibrary. However, we must use the class loader of the class attempting to load the library in this case, not the system classloader. Therefore, we now maintain a stack such that the latest class to load a library in the current thread is at the top, and we use that class whenever FindClass is called by ClassLoader.loadLibrary (via JNI_OnLoad). Note that this patch does not attempt to address the same problem for the Avian or Android class libraries, but the same strategy should work for them as well.
2014-06-23 17:17:13 -06:00
LibraryLoadStack* libraryLoadStack;
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
Resource* resource;
Checkpoint* checkpoint;
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
Runnable runnable;
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
uintptr_t* defaultHeap;
bugfixes
2007-09-12 21:15:16 -06:00
uintptr_t* heap;
pre-allocate Thread::backupHeap for signal safety It's not safe to use malloc from a signal handler, so we can't allocate new memory when handling segfaults or Thread.getStackTrace signals. Instead, we allocate a fixed-size backup heap for each thread ahead of time and use it if there's no space left in the normal heap pool. In the rare case that the backup heap isn't large enough, we fall back to using a preallocated exception without a stack trace as a last resort.
2010-06-19 16:40:21 -06:00
uintptr_t backupHeap[ThreadBackupHeapSizeInWords];
more progress on general stack tracing
2008-04-09 13:08:13 -06:00
unsigned backupHeapIndex;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
unsigned flags;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
};
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
class Classpath {
public:
virtual object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeJclass(Thread* t, GcClass* class_) = 0;
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
virtual object
makeString(Thread* t, object array, int32_t offset, int32_t length) = 0;
virtual object
makeThread(Thread* t, Thread* parent) = 0;
implement JNI reflection methods These include FromReflectedMethod, ToReflectedMethod, FromReflectedField, and ToReflectedField.
2012-12-19 12:39:33 -07:00
virtual object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeJMethod(Thread* t, GcMethod* vmMethod) = 0;
implement JNI reflection methods These include FromReflectedMethod, ToReflectedMethod, FromReflectedField, and ToReflectedField.
2012-12-19 12:39:33 -07:00
virtual object
getVMMethod(Thread* t, object jmethod) = 0;
virtual object
makeJField(Thread* t, object vmField) = 0;
virtual object
getVMField(Thread* t, object jfield) = 0;
set Thread.interrupted to true if thread is interrupted outside wait or sleep This is the correct behavior according to the Thread.interrupt JavaDoc, and it fixes an intermittent hang on exit in Eclipse.
2012-05-02 11:41:36 -06:00
virtual void
clearInterrupted(Thread* t) = 0;
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
virtual void
runThread(Thread* t) = 0;
load libfontmanager.so before trying to resolve FontManager.initIDs sun.font.FontManager.initIDs is a native method defined in libfontmanager.so, yet there seems to be no mechanism in OpenJDK's class library to actually load that library, so we lazily load it before trying to resolve the method.
2011-04-10 11:26:44 -06:00
virtual void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
resolveNative(Thread* t, GcMethod* method) = 0;
load libfontmanager.so before trying to resolve FontManager.initIDs sun.font.FontManager.initIDs is a native method defined in libfontmanager.so, yet there seems to be no mechanism in OpenJDK's class library to actually load that library, so we lazily load it before trying to resolve the method.
2011-04-10 11:26:44 -06:00
ensure that we can intercept static Java methods in bootimage build Timezone code was broken in the Android class library bootimage build because the code we use to intercept loading the tzdata file wasn't working. The reason is have no way of intercepting static methods at runtime in the bootimage build without telling the bootimage-generator we're going to do it ahead of time. So now we do tell it so. This commit also removes the need to intercept Thread methods since we can update Thread.vmThread in VMThread.create instead.
2013-03-15 13:28:01 -06:00
virtual void
interceptMethods(Thread* t) = 0;
fix openjdk build
2013-02-22 14:41:24 -07:00
virtual void
preBoot(Thread* t) = 0;
fix broken Android build due to 617bd85 617bd85 broke the Android build by creating an unresolvable order-of-operations bug in classpath-android.cpp's MyClasspath::preBoot method. The problem is that, while JNIEnv::FindClass is supposed to initialize the class that it finds, this causes JniConstants::init to indirectly invoke native methods which are not registered until JNI_OnLoad is called (which happens after JniConstants::init is called). However, if we call JNI_OnLoad first, that causes methods to be invoked which rely on JniConstants::init having already been run. I haven't checked to see how Dalvik handles this, but I don't see any way around the problem besides disabling initialization by JNIEnv::FindClass until the preBoot phase is complete. Moreover, it's dangerous to allow Java code to be invoked so early anyway, since the VM is not yet fully initialized.
2014-04-11 19:38:11 -06:00
virtual bool mayInitClasses() = 0;
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
virtual void
boot(Thread* t) = 0;
rework OpenJDK build to derive classpath and library path from environment We now consult the JAVA_HOME environment variable to determine where to find the system library JARs and SOs. Ultimately, we'll want to support self-contained build, but this allows Avian to behave like a conventional libjvm.so.
2010-09-20 17:31:23 -06:00
virtual const char*
bootClasspath() = 0;
more Android class library work
2013-02-21 15:37:17 -07:00
virtual object
makeDirectByteBuffer(Thread* t, void* p, jlong capacity) = 0;
virtual void*
getDirectBufferAddress(Thread* t, object buffer) = 0;
virtual int64_t
getDirectBufferCapacity(Thread* t, object buffer) = 0;
fix System.loadLibrary for OpenJDK tails=true build
2013-03-05 15:43:49 -07:00
virtual bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
canTailCall(Thread* t, GcMethod* caller, object calleeClassName,
fix System.loadLibrary for OpenJDK tails=true build
2013-03-05 15:43:49 -07:00
object calleeMethodName, object calleeMethodSpec) = 0;
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
virtual GcClassLoader* libraryClassLoader(Thread* t, GcMethod* caller) = 0;
fix JNIEnv::FindClass calls from JNI_OnLoad for all supported class libraries This also fixes the some Android build rot and updates the version of OpenSSL used.
2014-07-01 10:18:45 -06:00
run Shutdown.shutdown on exit when using OpenJDK library The OpenJDK library wants to track and run the shutdown hooks itself rather than let the VM do it, so we need to tell it when we're exiting. Also, in machine.cpp we need to use only the modifiers specified in the InnerClasses attribute for inner classes rather than OR them with the flags given at the top level of the class file.
2013-04-19 13:00:47 -06:00
virtual void
shutDown(Thread* t) = 0;
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
virtual void
dispose() = 0;
};
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
#ifdef _MSC_VER
template <class T>
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class ThreadRuntimeArray: public Thread::AutoResource {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
public:
fix MSVC build
2011-02-02 08:15:07 -07:00
ThreadRuntimeArray(Thread* t, unsigned size):
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t),
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
body(static_cast<T*>(t->m->heap->allocate(size * sizeof(T)))),
size(size)
{ }
fix MSVC build
2011-02-02 08:15:07 -07:00
~ThreadRuntimeArray() {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
t->m->heap->free(body, size * sizeof(T));
}
virtual void release() {
fix MSVC build
2011-02-02 08:15:07 -07:00
ThreadRuntimeArray::~ThreadRuntimeArray();
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
}
T* body;
unsigned size;
};
# define THREAD_RUNTIME_ARRAY(thread, type, name, size) \
fix MSVC build
2011-02-02 08:15:07 -07:00
ThreadRuntimeArray<type> name(thread, size);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
#else // not _MSC_VER
modify (THREAD_)RUNTIME_ARRAY definition so RUNTIME_ARRAY_BODY must be used Previously, if you forgot to use RUNTIME_ARRAY_BODY to reference an array declared with (THREAD_)RUNTIME_ARRAY, you wouldn't get a compiler error until you tried to build on e.g. MSVC, where runtime-sized stack arrays aren't supported. This change ensures you find out regardless of what compiler you're using, which ought to protect us from regressions going forward.
2013-02-20 17:20:17 -07:00
# define THREAD_RUNTIME_ARRAY(thread, type, name, size) \
type name##_body[size];
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
#endif // not _MSC_VER
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
Classpath*
add support for accessing embedded JARs as if they were directories This allows OpenJDK to access time zone data which is normally found under java.home, but which we must embed in the executable itself to create a self-contained build. The VM intercepts various file operations, looking for paths which start with a prefix specified by the avian.embed.prefix property and redirecting those operations to an embedded JAR. For example, if avian.embed.prefix is "/avian-embedded", and code calls File.exists() with a path of "/avian-embedded/javahomeJar/foo.txt", the VM looks for a function named javahomeJar via dlsym, calls the function to find the memory region containing the embeded JAR, and finally consults the JAR to see if the file "foo.txt" exists.
2010-11-05 13:18:28 -06:00
makeClasspath(System* system, Allocator* allocator, const char* javaHome,
const char* embedPrefix);
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
typedef uint64_t (JNICALL *FastNativeFunction)(Thread*, GcMethod*, uintptr_t*);
early sketch of continuation support
2009-05-03 14:57:11 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
objectClass(Thread*, object o)
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return reinterpret_cast<GcClass*>(maskAlignedPointer(fieldAtOffset<object>(o, 0)));
}
inline GcClass*
objectClass(Thread*, GcObject* o)
{
return reinterpret_cast<GcClass*>(maskAlignedPointer(fieldAtOffset<object>(o, 0)));
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
implement -Xss command line option
2012-03-14 12:36:42 -06:00
inline unsigned
stackSizeInWords(Thread* t)
{
return t->m->stackSizeInBytes / BytesPerWord;
}
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
void
enter(Thread* t, Thread::State state);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
fix a few threading bugs in windows port
2007-10-23 16:21:28 -06:00
inline void
enterActiveState(Thread* t)
{
enter(t, Thread::ActiveState);
}
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class StateResource: public Thread::AutoResource {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
public:
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
StateResource(Thread* t, Thread::State state):
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t), oldState(t->state)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
enter(t, state);
}
~StateResource() { enter(t, oldState); }
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
virtual void release() {
this->StateResource::~StateResource();
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
private:
Thread::State oldState;
};
implement Processor::makeLocalReference()/disposeLocalReference()
2007-09-29 21:33:38 -06:00
inline void
dispose(Thread* t, Reference* r)
{
*(r->handle) = r->next;
implement additional instructions for JIT; fix bug in dispose(Thread*,Reference*)
2007-10-08 15:41:41 -06:00
if (r->next) {
r->next->handle = r->handle;
}
simplify memory allocation interfaces
2008-04-13 12:15:04 -06:00
t->m->heap->free(r, sizeof(*r));
implement Processor::makeLocalReference()/disposeLocalReference()
2007-09-29 21:33:38 -06:00
}
reuse JNI references when possible Before allocating a new reference in NewGlobalReference or when creating a local reference, we look for a previously-allocated reference pointing to the same object. This is a linear search, but usually the number of elements in the reference list is small, whereas the memory, locking, and allocation overhead of creating duplicate references can be large.
2009-12-16 19:16:51 -07:00
inline void
acquire(Thread*, Reference* r)
{
++ r->count;
}
inline void
release(Thread* t, Reference* r)
{
if ((-- r->count) == 0) {
dispose(t, r);
}
}
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
void
fix unintentionally retained finalizables and improve low mem performance Objects which are eligable for finalization must be retained until after their finalize methods are called. However, the VM must determine the entire set of such objects before retaining any of them; otherwise the process of retaining a given object may cause others to become reachable and thus be considered ineligible for finalization even though they are only reachable via other finalizable objects. The end result of this mistake is that only a few of the objects which are finalizable will be recognized at each GC cycle, so it requires many such cycles to find them all, and if new objects become finalizable at a faster rate, the VM will never catch up and eventually run out of memory. This patch fixes the above mistake and also includes tuning to minimize the need for GC in low memory situations.
2013-03-07 20:17:05 -07:00
collect(Thread* t, Heap::CollectionType type, int pendingAllocation = 0);
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
implement Runtime.addShutdownHook and Thread.setDaemon; avoid segfaults due to an application calling e.g. CallStaticBooleanMethod when it really meant CallStaticVoidMethod
2009-08-19 14:27:03 -06:00
void
shutDown(Thread* t);
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
#ifdef VM_STRESS
inline void
stress(Thread* t)
{
fix GC safety bugs
2010-12-09 22:17:57 -07:00
if ((not t->m->unsafe)
and (t->flags & (Thread::StressFlag | Thread::TracingFlag)) == 0
more GC stress fixes
2007-07-16 18:23:23 -06:00
and t->state != Thread::NoState
and t->state != Thread::IdleState)
{
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
atomicOr(&(t->flags), Thread::StressFlag);
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
# ifdef VM_STRESS_MAJOR
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
collect(t, Heap::MajorCollection);
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
# else // not VM_STRESS_MAJOR
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
collect(t, Heap::MinorCollection);
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
# endif // not VM_STRESS_MAJOR
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
atomicAnd(&(t->flags), ~Thread::StressFlag);
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
}
}
#endif // not VM_STRESS
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
inline void
acquire(Thread* t, System::Monitor* m)
{
if (not m->tryAcquire(t->systemThread)) {
ENTER(t, Thread::IdleState);
m->acquire(t->systemThread);
}
stress(t);
}
inline void
release(Thread* t, System::Monitor* m)
{
m->release(t->systemThread);
}
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
class MonitorResource: public Thread::AutoResource {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
public:
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
MonitorResource(Thread* t, System::Monitor* m):
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
AutoResource(t), m(m)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
acquire(t, m);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
~MonitorResource() {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
vm::release(t, m);
}
virtual void release() {
this->MonitorResource::~MonitorResource();
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
private:
System::Monitor* m;
};
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
class RawMonitorResource: public Thread::Resource {
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
public:
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
RawMonitorResource(Thread* t, System::Monitor* m):
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
Resource(t, t->resource), m(m)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
various bugfixes
2007-08-13 18:37:00 -06:00
m->acquire(t->systemThread);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
~RawMonitorResource() {
fix crash on exit due to order of operations bug in ~RawMonitorResource The problem (which we've only been able to reproduce consistently with the openjdk-src process=interpret build on Linux virtual machines) was a race condition during VM shutdown. Thread "A" would exit, see there were other threads still running and thus enter ZombieState, which involves acquiring and releasing a lock using RawMonitorResource. Then the last thread (thread "B") would exit, wait for thread "A" to release the lock, then shut down the VM, freeing all memory. However, thread "A" writes to its Thread object one last time after releasing the lock (in ~Resource, the destructor of the superclass of RawMonitorResource, which sets Thread::resource). If thread "B" frees that Thread before ~Resource runs, we end up writing to freed memory. Thus, we need to update Thread::resource before releasing the lock. Apparently C++ destructors run in order from most derived to least derived, which is not what we want here. My solution to split Resource into two classes, one that has no destructor and another that extends it (called AutoResource) which does hafe a destructor. Now all the classes which used to extend Resource extend AutoResource, except for RawMonitorResource, which extends Resource directly so it can control the order of operations.
2014-05-10 23:06:29 -06:00
t->resource = next;
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
vm::release(t, m);
}
virtual void release() {
this->RawMonitorResource::~RawMonitorResource();
acquire class lock before running static initializer; wrap exceptions thrown from static initializers in ExceptionInInitializerError instances
2007-08-01 17:48:36 -06:00
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
private:
System::Monitor* m;
};
factor out assert / abort / expect implementations
2013-02-11 18:51:39 -07:00
inline Aborter* getAborter(Thread* t) {
return t->m->system;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
pre-allocate Thread::backupHeap for signal safety It's not safe to use malloc from a signal handler, so we can't allocate new memory when handling segfaults or Thread.getStackTrace signals. Instead, we allocate a fixed-size backup heap for each thread ahead of time and use it if there's no space left in the normal heap pool. In the rare case that the backup heap isn't large enough, we fall back to using a preallocated exception without a stack trace as a last resort.
2010-06-19 16:40:21 -06:00
inline bool
more progress on general stack tracing
2008-04-09 13:08:13 -06:00
ensure(Thread* t, unsigned sizeInBytes)
{
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
if (t->heapIndex + ceilingDivide(sizeInBytes, BytesPerWord)
increase heap pool size and fixed footprint threshold constants based on performance profiling and experimentation
2008-11-22 14:47:18 -07:00
> ThreadHeapSizeInWords)
more progress on general stack tracing
2008-04-09 13:08:13 -06:00
{
pre-allocate Thread::backupHeap for signal safety It's not safe to use malloc from a signal handler, so we can't allocate new memory when handling segfaults or Thread.getStackTrace signals. Instead, we allocate a fixed-size backup heap for each thread ahead of time and use it if there's no space left in the normal heap pool. In the rare case that the backup heap isn't large enough, we fall back to using a preallocated exception without a stack trace as a last resort.
2010-06-19 16:40:21 -06:00
if (sizeInBytes <= ThreadBackupHeapSizeInBytes) {
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
expect(t, (t->flags & Thread::UseBackupHeapFlag) == 0);
zero heap space ahead of time when allocating raw storage and garbage collecting, not when allocating individual objects This helps us support the Java Memory Model without adding a memory barrier to every object allocation. It's also potentially more efficient, since we zero out each heap segment all at once instead of bit-by-bit with each object allocation.
2009-03-03 20:05:48 -07:00
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
atomicOr(&(t->flags), Thread::UseBackupHeapFlag);
zero heap space ahead of time when allocating raw storage and garbage collecting, not when allocating individual objects This helps us support the Java Memory Model without adding a memory barrier to every object allocation. It's also potentially more efficient, since we zero out each heap segment all at once instead of bit-by-bit with each object allocation.
2009-03-03 20:05:48 -07:00
pre-allocate Thread::backupHeap for signal safety It's not safe to use malloc from a signal handler, so we can't allocate new memory when handling segfaults or Thread.getStackTrace signals. Instead, we allocate a fixed-size backup heap for each thread ahead of time and use it if there's no space left in the normal heap pool. In the rare case that the backup heap isn't large enough, we fall back to using a preallocated exception without a stack trace as a last resort.
2010-06-19 16:40:21 -06:00
return true;
} else {
return false;
}
} else {
return true;
more progress on general stack tracing
2008-04-09 13:08:13 -06:00
}
}
implement fixed object support
2007-10-27 19:54:30 -06:00
object
refactor memory management code We now support immortal objects, which the GC will scan for references but not consider for collection. On x86_64, we allocate JIT code memory via mmap, which lets us map memory into the bottom 2GB of the address space, ensuring that 32-bit relative jumps and calls work.
2008-01-09 18:20:36 -07:00
allocate2(Thread* t, unsigned sizeInBytes, bool objectMask);
object
allocate3(Thread* t, Allocator* allocator, Machine::AllocationType type,
simplify memory allocation interfaces
2008-04-13 12:15:04 -06:00
unsigned sizeInBytes, bool objectMask);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
inline object
allocateSmall(Thread* t, unsigned sizeInBytes)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, t->heapIndex + ceilingDivide(sizeInBytes, BytesPerWord)
fix thread heap overflow corner case in allocate3 The previous code relied on the invalid assumption that the thread-local heaps for all threads would have been cleared immediately following a garbage collection. However, the last thing the garbage collection function does is run finalizers which may allocate new objects. This can lead allocate3 to call allocateSmall with a size which is too large to accomodate, overflowing the heap. The solution is to iterate until there really is enough room for the original allocation request.
2009-07-17 19:37:46 -06:00
<= ThreadHeapSizeInWords);
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
object o = reinterpret_cast<object>(t->heap + t->heapIndex);
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
t->heapIndex += ceilingDivide(sizeInBytes, BytesPerWord);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
return o;
}
inline object
implement fixed object support
2007-10-27 19:54:30 -06:00
allocate(Thread* t, unsigned sizeInBytes, bool objectMask)
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
{
implement primitive testing framework and provide for GC stress testing
2007-07-15 19:03:02 -06:00
stress(t);
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
if (UNLIKELY(t->heapIndex + ceilingDivide(sizeInBytes, BytesPerWord)
increase heap pool size and fixed footprint threshold constants based on performance profiling and experimentation
2008-11-22 14:47:18 -07:00
> ThreadHeapSizeInWords
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
or t->m->exclusive))
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
{
refactor memory management code We now support immortal objects, which the GC will scan for references but not consider for collection. On x86_64, we allocate JIT code memory via mmap, which lets us map memory into the bottom 2GB of the address space, ensuring that 32-bit relative jumps and calls work.
2008-01-09 18:20:36 -07:00
return allocate2(t, sizeInBytes, objectMask);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
} else {
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, t->criticalLevel == 0);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
return allocateSmall(t, sizeInBytes);
}
}
move fixed object (mark and sweep) support into heap.cpp and refine algorithms for determining when and how much to GC
2007-10-28 13:14:53 -06:00
inline void
mark(Thread* t, object o, unsigned offset, unsigned count)
{
use atomic operations in MyHeap::mark to avoid need for mutex
2009-11-19 18:13:00 -07:00
t->m->heap->mark(o, offset / BytesPerWord, count);
move fixed object (mark and sweep) support into heap.cpp and refine algorithms for determining when and how much to GC
2007-10-28 13:14:53 -06:00
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
move fixed object (mark and sweep) support into heap.cpp and refine algorithms for determining when and how much to GC
2007-10-28 13:14:53 -06:00
inline void
mark(Thread* t, object o, unsigned offset)
{
use atomic operations in MyHeap::mark to avoid need for mutex
2009-11-19 18:13:00 -07:00
t->m->heap->mark(o, offset / BytesPerWord, 1);
move fixed object (mark and sweep) support into heap.cpp and refine algorithms for determining when and how much to GC
2007-10-28 13:14:53 -06:00
}
implement fixed object support
2007-10-27 19:54:30 -06:00
snapshot
2008-07-05 14:21:13 -06:00
inline void
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
set(Thread* t, object target, unsigned offset, object value)
fix various bugs uncovered in GC stress test
2007-07-16 17:58:37 -06:00
{
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
fieldAtOffset<object>(target, offset) = value;
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
mark(t, target, offset);
fix various bugs uncovered in GC stress test
2007-07-16 17:58:37 -06:00
}
add util.cpp/.h changes
2014-06-28 14:41:27 -06:00
inline void
set(Thread* t, GcObject* target, unsigned offset, GcObject* value)
{
fieldAtOffset<GcObject*>(target, offset) = value;
mark(t, reinterpret_cast<object>(target), offset);
}
inline void
setObject(Thread* t, GcObject* target, unsigned offset, GcObject* value)
{
set(t, target, offset, value);
}
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
inline void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
setObjectClass(Thread*, object o, GcClass* c)
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
{
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
fieldAtOffset<object>(o, 0)
refactor memory management code We now support immortal objects, which the GC will scan for references but not consider for collection. On x86_64, we allocate JIT code memory via mmap, which lets us map memory into the bottom 2GB of the address space, ensuring that 32-bit relative jumps and calls work.
2008-01-09 18:20:36 -07:00
= reinterpret_cast<object>
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
(reinterpret_cast<intptr_alias_t>(c)
work around GCC name mangling bug It seems that older versions of GCC (4.0 and older, at least) generate assembly files with duplicate symbols for function templates which differ only by the attributes of the templated types. Newer versions have no such problem, but we need to support both, hence the workaround in this commit of using a dedicated, non-template "alias" function where we previously used "cast<alias_t>".
2011-02-14 11:47:59 -07:00
| (reinterpret_cast<intptr_alias_t>
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
(fieldAtOffset<object>(o, 0)) & (~PointerMask)));
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
}
Merge branch 'master' into powerpc Conflicts: makefile src/assembler.h src/compile.cpp src/compiler.cpp src/compiler.h src/finder.cpp
2008-11-11 08:20:49 -07:00
inline const char*
findProperty(Machine* m, const char* name)
{
for (unsigned i = 0; i < m->propertyCount; ++i) {
const char* p = m->properties[i];
const char* n = name;
while (*p and *p != '=' and *n and *p == *n) {
++ p;
++ n;
}
if (*p == '=' and *n == 0) {
return p + 1;
}
}
return 0;
}
inline const char*
findProperty(Thread* t, const char* name)
{
return findProperty(t->m, name);
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
object&
arrayBodyUnsafe(Thread*, object, unsigned);
clean up bootstrap type generation to eliminate redundancy (broken)
2007-11-04 14:15:28 -07:00
bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
instanceOf(Thread* t, GcClass* class_, object o);
template <class T>
T* GcObject::as(Thread* t UNUSED)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
t->m->unsafe
|| instanceOf(t, reinterpret_cast<GcClass*>(arrayBodyUnsafe(t, t->m->types, T::Type)), reinterpret_cast<object>(this)));
return static_cast<T*>(this);
}
template <class T>
bool GcObject::isa(Thread* t)
{
return instanceOf(t, reinterpret_cast<GcClass*>(arrayBodyUnsafe(t, t->m->types, T::Type)), reinterpret_cast<object>(this));
}
template <class T>
T* cast(Thread* t UNUSED, object o)
{
if(o == 0) {
return 0;
}
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
t->m->unsafe || instanceOf(t,
reinterpret_cast<GcClass*>(arrayBodyUnsafe(
t, t->m->types, T::Type)),
o));
return reinterpret_cast<T*>(o);
}
clean up bootstrap type generation to eliminate redundancy (broken)
2007-11-04 14:15:28 -07:00
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
#include "type-declarations.cpp"
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
inline object&
arrayBodyUnsafe(Thread*, object a, unsigned index)
{
return reinterpret_cast<GcArray*>(a)->body()[index];
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
inline uint64_t
avoid deadlock due to entering active state before running destroyJavaVM We risked deadlock when waiting for other non-daemon threads to exit since they could not exit without entering exclusive state, which required waiting for all other threads to go idle.
2011-02-01 17:45:43 -07:00
runRaw(Thread* t,
uint64_t (*function)(Thread*, uintptr_t*), uintptr_t* arguments)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
Thread::RunCheckpoint checkpoint(t);
return vmRun(function, arguments, &checkpoint);
}
avoid deadlock due to entering active state before running destroyJavaVM We risked deadlock when waiting for other non-daemon threads to exit since they could not exit without entering exclusive state, which required waiting for all other threads to go idle.
2011-02-01 17:45:43 -07:00
inline uint64_t
run(Thread* t, uint64_t (*function)(Thread*, uintptr_t*), uintptr_t* arguments)
{
ENTER(t, Thread::ActiveState);
return runRaw(t, function, arguments);
}
handle case of not-yet-started thread in setDaemon
2010-12-01 15:42:46 -07:00
inline void
runJavaThread(Thread* t)
{
t->m->classpath->runThread(t);
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
void
runFinalizeThread(Thread* t);
inline uint64_t
runThread(Thread* t, uintptr_t*)
{
t->m->localThread->set(t);
checkDaemon(t);
if (t == t->m->finalizeThread) {
runFinalizeThread(t);
} else if (t->javaThread) {
runJavaThread(t);
}
return 1;
}
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
inline bool
startThread(Thread* t, Thread* p)
{
avoid running out of OS resources due to zombie thread accumulation (part 2) My previous attempt wasn't quite sufficient, since it was too late to call join on a thread which had already exited given the code was written to aggressively dispose of system handles as soon as the thread exited. The solution is to delay disposing these handles until after we're able to join the thread.
2012-02-03 17:20:20 -07:00
p->flags |= Thread::JoinFlag;
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
return t->m->system->success(t->m->system->start(&(p->runnable)));
}
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
inline void
addThread(Thread* t, Thread* p)
{
ACQUIRE_RAW(t, t->m->stateLock);
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, p->state == Thread::NoState);
Adding another possible case for addThread to expect. One common case that triggers is is when both arguments to addThread are the same thread (such as the call from attachThread). SWT on darwin seems to do this for dialog boxes.
2013-07-14 15:59:43 -06:00
expect(t, t->state == Thread::ActiveState || t->state == Thread::ExclusiveState || t->state == Thread::NoState);
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
p->state = Thread::IdleState;
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
++ t->m->threadCount;
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
++ t->m->liveCount;
p->peer = p->parent->child;
p->parent->child = p;
fix various regressions due to 0.5 work
2011-02-11 21:13:11 -07:00
handle null p->javaThread in addThread and removeThread These functions may be called when p->javaThread is null, in which case we must not try to set the threadPeer field.
2011-02-15 08:47:48 -07:00
if (p->javaThread) {
threadPeer(t, p->javaThread) = reinterpret_cast<jlong>(p);
}
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
}
inline void
removeThread(Thread* t, Thread* p)
{
ACQUIRE_RAW(t, t->m->stateLock);
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, p->state == Thread::IdleState);
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
-- t->m->liveCount;
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
-- t->m->threadCount;
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
t->m->stateLock->notifyAll(t->systemThread);
p->parent->child = p->peer;
fix various regressions due to 0.5 work
2011-02-11 21:13:11 -07:00
handle null p->javaThread in addThread and removeThread These functions may be called when p->javaThread is null, in which case we must not try to set the threadPeer field.
2011-02-15 08:47:48 -07:00
if (p->javaThread) {
threadPeer(t, p->javaThread) = 0;
}
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
p->dispose();
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
}
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
inline Thread*
better statically type Processor interface
2014-06-28 13:16:26 -06:00
startThread(Thread* t, GcThread* javaThread)
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
{
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
{ PROTECT(t, javaThread);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
stress(t);
ACQUIRE_RAW(t, t->m->stateLock);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
avoid running out of OS resources due to zombie thread accumulation The bug here is that when a thread exits and becomes a "zombie", the OS resources associated with it are not necessarily released until we actually join and dispose of that thread. Since that only happens during garbage collection, and collection normally only happens in response to heap memory pressure, there's no guarantee that we'll GC frequently enough to clean up zombies promptly and avoid running out of resources. The solution is to force a GC whenever we start a new thread and there are at least N zombies waiting to be disposed, where N=16 for now.
2012-02-03 12:00:02 -07:00
if (t->m->threadCount > t->m->liveCount + ZombieCollectionThreshold) {
collect(t, Heap::MinorCollection);
}
}
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
Thread* p = t->m->processor->makeThread(t->m, javaThread, t);
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
addThread(t, p);
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
if (startThread(t, p)) {
return p;
} else {
fix race condition leading to deadlock on exit There is a delay between when we tell the OS to start a thread and when it actually starts, and during that time a thread might mistakenly think it was the last to exit, try to shut down the VM, and then block in joinAll when it finds it wasn't the last one after all. The solution is to increment Machine::liveCount and add the new thread to the process tree before starting it -- all while holding Machine::stateLock for atomicity. This helps guarantee that when liveCount is one, we can be sure there's really only one thread running or staged to run.
2010-12-20 19:00:23 -07:00
removeThread(t, p);
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
return 0;
}
}
inline void
registerDaemon(Thread* t)
{
ACQUIRE_RAW(t, t->m->stateLock);
atomicOr(&(t->flags), Thread::DaemonFlag);
++ t->m->daemonCount;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
t->m->stateLock->notifyAll(t->systemThread);
}
inline void
checkDaemon(Thread* t)
{
if (threadDaemon(t, t->javaThread)) {
registerDaemon(t);
}
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
inline uint64_t
initAttachedThread(Thread* t, uintptr_t* arguments)
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
{
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
bool daemon = arguments[0];
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
t->javaThread = t->m->classpath->makeThread(t, t->m->rootThread);
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
threadPeer(t, t->javaThread) = reinterpret_cast<jlong>(t);
if (daemon) {
threadDaemon(t, t->javaThread) = true;
registerDaemon(t);
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
t->m->localThread->set(t);
return 1;
}
inline Thread*
attachThread(Machine* m, bool daemon)
{
Thread* t = m->processor->makeThread(m, 0, m->rootThread);
m->system->attach(&(t->runnable));
addThread(t, t);
enter(t, Thread::ActiveState);
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
return false if javaThread is null in Thread::Runnable::interrupted This field may be null if the thread is in the process of being attached to the VM.
2011-02-15 21:44:27 -07:00
uintptr_t arguments[] = { daemon };
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
if (run(t, initAttachedThread, arguments)) {
enter(t, Thread::IdleState);
return t;
} else {
t->exit();
return 0;
}
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
}
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
inline object&
root(Thread* t, Machine::Root root)
{
return arrayBody(t, t->m->roots, root);
}
inline void
setRoot(Thread* t, Machine::Root root, object value)
{
set(t, t->m->roots, ArrayBody + (root * BytesPerWord), value);
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
type(Thread* t, Gc::Type type)
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcClass>(t, arrayBody(t, t->m->types, type));
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
}
inline void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
setType(Thread* t, Gc::Type type, GcClass* value)
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
set(t, t->m->types, ArrayBody + (type * BytesPerWord), reinterpret_cast<object>(value));
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
}
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
inline bool
objectFixed(Thread*, object o)
{
work around GCC name mangling bug It seems that older versions of GCC (4.0 and older, at least) generate assembly files with duplicate symbols for function templates which differ only by the attributes of the templated types. Newer versions have no such problem, but we need to support both, hence the workaround in this commit of using a dedicated, non-template "alias" function where we previously used "cast<alias_t>".
2011-02-14 11:47:59 -07:00
return (alias(o, 0) & (~PointerMask)) == FixedMark;
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
}
inline bool
objectExtended(Thread*, object o)
{
work around GCC name mangling bug It seems that older versions of GCC (4.0 and older, at least) generate assembly files with duplicate symbols for function templates which differ only by the attributes of the templated types. Newer versions have no such problem, but we need to support both, hence the workaround in this commit of using a dedicated, non-template "alias" function where we previously used "cast<alias_t>".
2011-02-14 11:47:59 -07:00
return (alias(o, 0) & (~PointerMask)) == ExtendedMark;
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
}
inline bool
hashTaken(Thread*, object o)
{
work around GCC name mangling bug It seems that older versions of GCC (4.0 and older, at least) generate assembly files with duplicate symbols for function templates which differ only by the attributes of the templated types. Newer versions have no such problem, but we need to support both, hence the workaround in this commit of using a dedicated, non-template "alias" function where we previously used "cast<alias_t>".
2011-02-14 11:47:59 -07:00
return (alias(o, 0) & (~PointerMask)) == HashTakenMark;
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
}
inline unsigned
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
baseSize(Thread* t UNUSED, object o, GcClass* class_)
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, class_->fixedSize() >= BytesPerWord);
fix bug in isAssignableFrom such that primitive array types were considered to be subclasses of the Object array type
2012-02-27 18:16:01 -07:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return ceilingDivide(class_->fixedSize(), BytesPerWord)
+ ceilingDivide(class_->arrayElementSize()
* fieldAtOffset<uintptr_t>(o, class_->fixedSize() - BytesPerWord),
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
BytesPerWord);
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
object
refactor stack walking interface in processor.h and sketch stack walking implementation in compile2.cpp
2007-11-25 16:00:55 -07:00
makeTrace(Thread* t, Processor::StackWalker* walker);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
refactor stack walking interface in processor.h and sketch stack walking implementation in compile2.cpp
2007-11-25 16:00:55 -07:00
object
more progress on general stack tracing
2008-04-09 13:08:13 -06:00
makeTrace(Thread* t, Thread* target);
inline object
makeTrace(Thread* t)
{
return makeTrace(t, t);
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
snapshot
2008-07-05 14:21:13 -06:00
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeNew(Thread* t, GcClass* class_)
add a few more instructions to compile.cpp and fix bugs in others; invokespecial and invokevirtual are working
2007-09-27 16:20:54 -06:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, t->state == Thread::NoState or t->state == Thread::ActiveState);
remove unused function and add some thread state assertions
2008-01-17 18:27:44 -07:00
add a few more instructions to compile.cpp and fix bugs in others; invokespecial and invokevirtual are working
2007-09-27 16:20:54 -06:00
PROTECT(t, class_);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
unsigned sizeInBytes = pad(class_->fixedSize());
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, sizeInBytes);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
object instance = allocate(t, sizeInBytes, class_->objectMask());
implement fixed object support
2007-10-27 19:54:30 -06:00
setObjectClass(t, instance, class_);
add a few more instructions to compile.cpp and fix bugs in others; invokespecial and invokevirtual are working
2007-09-27 16:20:54 -06:00
return instance;
}
implement basic finalization support This implementation does not conform to the Java standard in that finalize methods are called from whichever thread happens to be garbage collecting, and that thread may hold locks, whereas the standard guarantees that finalize will be run from a thread which holds no locks. Also, an object will never be finalized more than once, even if its finalize method "rescues" (i.e. makes reachable) the object such that it might become unreachable a second time and thus a candidate for finalization once more. It's not clear to me from the standard if this is OK or not. Nonwithstanding the above, this implementation is useful for "normal" finalize methods which simply release resources associated with an object.
2009-07-21 18:57:55 -06:00
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeNewGeneral(Thread* t, GcClass* class_);
add a few more instructions to compile.cpp and fix bugs in others; invokespecial and invokevirtual are working
2007-09-27 16:20:54 -06:00
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
make(Thread* t, GcClass* class_)
add a few more instructions to compile.cpp and fix bugs in others; invokespecial and invokevirtual are working
2007-09-27 16:20:54 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (UNLIKELY(class_->vmFlags()
implement basic finalization support This implementation does not conform to the Java standard in that finalize methods are called from whichever thread happens to be garbage collecting, and that thread may hold locks, whereas the standard guarantees that finalize will be run from a thread which holds no locks. Also, an object will never be finalized more than once, even if its finalize method "rescues" (i.e. makes reachable) the object such that it might become unreachable a second time and thus a candidate for finalization once more. It's not clear to me from the standard if this is OK or not. Nonwithstanding the above, this implementation is useful for "normal" finalize methods which simply release resources associated with an object.
2009-07-21 18:57:55 -06:00
& (WeakReferenceFlag | HasFinalizerFlag)))
{
return makeNewGeneral(t, class_);
add a few more instructions to compile.cpp and fix bugs in others; invokespecial and invokevirtual are working
2007-09-27 16:20:54 -06:00
} else {
return makeNew(t, class_);
}
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
object
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
makeByteArrayV(Thread* t, const char* format, va_list a, int size);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
object
makeByteArray(Thread* t, const char* format, ...);
object
makeString(Thread* t, const char* format, ...);
fix build for recent versions of OpenJDK 7 As of the latest code from the jdk7u-dev Mercurial repository, java.lang.String no longer has offset or length fields. Instead, the content fits exactly into the backing char array, so offset is implicitly zero and length is the length of the array. The VM previously relied on those fields being present, whereas this commit handles the case where they are not. In addition, I've made some changes to openjdk-src.mk to ensure that we can build against both a stock OpenJDK 7 and an IcedTea-patched version.
2012-06-11 23:30:22 +00:00
#ifndef HAVE_StringOffset
inline unsigned
stringLength(Thread* t, object string)
{
fix mode=debug build for recent OpenJDK versions
2012-06-12 16:32:27 -06:00
return charArrayLength(t, stringData(t, string));
fix build for recent versions of OpenJDK 7 As of the latest code from the jdk7u-dev Mercurial repository, java.lang.String no longer has offset or length fields. Instead, the content fits exactly into the backing char array, so offset is implicitly zero and length is the length of the array. The VM previously relied on those fields being present, whereas this commit handles the case where they are not. In addition, I've made some changes to openjdk-src.mk to ensure that we can build against both a stock OpenJDK 7 and an IcedTea-patched version.
2012-06-11 23:30:22 +00:00
}
inline unsigned
stringOffset(Thread*, object)
{
return 0;
}
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
# ifndef HAVE_StringHash32
inline object
makeString(Thread* t, object data, int32_t hash, int32_t)
{
return makeString(t, data, hash);
}
# endif // not HAVE_StringHash32
fix build for recent versions of OpenJDK 7 As of the latest code from the jdk7u-dev Mercurial repository, java.lang.String no longer has offset or length fields. Instead, the content fits exactly into the backing char array, so offset is implicitly zero and length is the length of the array. The VM previously relied on those fields being present, whereas this commit handles the case where they are not. In addition, I've made some changes to openjdk-src.mk to ensure that we can build against both a stock OpenJDK 7 and an IcedTea-patched version.
2012-06-11 23:30:22 +00:00
inline object
makeString(Thread* t, object data, unsigned offset, unsigned length, unsigned)
{
fix mode=debug build for recent OpenJDK versions
2012-06-12 16:32:27 -06:00
if (offset == 0 and length == charArrayLength(t, data)) {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return reinterpret_cast<object>(makeString(t, data, 0, 0));
fix build for recent versions of OpenJDK 7 As of the latest code from the jdk7u-dev Mercurial repository, java.lang.String no longer has offset or length fields. Instead, the content fits exactly into the backing char array, so offset is implicitly zero and length is the length of the array. The VM previously relied on those fields being present, whereas this commit handles the case where they are not. In addition, I've made some changes to openjdk-src.mk to ensure that we can build against both a stock OpenJDK 7 and an IcedTea-patched version.
2012-06-11 23:30:22 +00:00
} else {
PROTECT(t, data);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
object array = reinterpret_cast<object>(makeCharArray(t, length));
fix build for recent versions of OpenJDK 7 As of the latest code from the jdk7u-dev Mercurial repository, java.lang.String no longer has offset or length fields. Instead, the content fits exactly into the backing char array, so offset is implicitly zero and length is the length of the array. The VM previously relied on those fields being present, whereas this commit handles the case where they are not. In addition, I've made some changes to openjdk-src.mk to ensure that we can build against both a stock OpenJDK 7 and an IcedTea-patched version.
2012-06-11 23:30:22 +00:00
memcpy(&charArrayBody(t, array, 0), &charArrayBody(t, data, offset),
length * 2);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return reinterpret_cast<object>(makeString(t, array, 0, 0));
fix build for recent versions of OpenJDK 7 As of the latest code from the jdk7u-dev Mercurial repository, java.lang.String no longer has offset or length fields. Instead, the content fits exactly into the backing char array, so offset is implicitly zero and length is the length of the array. The VM previously relied on those fields being present, whereas this commit handles the case where they are not. In addition, I've made some changes to openjdk-src.mk to ensure that we can build against both a stock OpenJDK 7 and an IcedTea-patched version.
2012-06-11 23:30:22 +00:00
}
}
#endif // not HAVE_StringOffset
Improved (should now be complete) Unicode support (UTF-8 for *nix and UTF-16 for Windows).
2010-04-20 10:03:07 -06:00
int
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
stringUTFLength(Thread* t, object string, unsigned start, unsigned length);
inline int
stringUTFLength(Thread* t, object string)
{
return stringUTFLength(t, string, 0, stringLength(t, string));
}
Improved (should now be complete) Unicode support (UTF-8 for *nix and UTF-16 for Windows).
2010-04-20 10:03:07 -06:00
snapshot; known bug: finalizers and weak references don't work correctly wrt tenured objects
2007-07-07 19:06:32 -06:00
void
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
stringChars(Thread* t, object string, unsigned start, unsigned length,
char* chars);
inline void
stringChars(Thread* t, object string, char* chars)
{
stringChars(t, string, 0, stringLength(t, string), chars);
}
snapshot; known bug: finalizers and weak references don't work correctly wrt tenured objects
2007-07-07 19:06:32 -06:00
implement GetStringLength, GetStringChars, and ReleaseStringChars
2008-04-01 17:24:43 -06:00
void
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
stringChars(Thread* t, object string, unsigned start, unsigned length,
uint16_t* chars);
inline void
stringChars(Thread* t, object string, uint16_t* chars)
{
stringChars(t, string, 0, stringLength(t, string), chars);
}
implement GetStringLength, GetStringChars, and ReleaseStringChars
2008-04-01 17:24:43 -06:00
Improved (should now be complete) Unicode support (UTF-8 for *nix and UTF-16 for Windows).
2010-04-20 10:03:07 -06:00
void
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
stringUTFChars(Thread* t, object string, unsigned start, unsigned length,
char* chars, unsigned charsLength);
inline void
stringUTFChars(Thread* t, object string, char* chars, unsigned charsLength)
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
stringUTFChars(t, string, 0, stringLength(t, string), chars, charsLength);
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
}
Improved (should now be complete) Unicode support (UTF-8 for *nix and UTF-16 for Windows).
2010-04-20 10:03:07 -06:00
start work on reflection; bugfixes
2007-07-23 19:44:20 -06:00
bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
isAssignableFrom(Thread* t, GcClass* a, GcClass* b);
start work on reflection; bugfixes
2007-07-23 19:44:20 -06:00
misc. bugfixes and tweaks
2007-07-28 10:10:13 -06:00
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
classInitializer(Thread* t, GcClass* class_);
misc. bugfixes and tweaks
2007-07-28 10:10:13 -06:00
sketch of Runtime.exec() and Calendar; misc bugfixes
2007-09-12 18:21:37 -06:00
object
frameMethod(Thread* t, int frame);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
inline uintptr_t&
various performance tweaks and bugfixes
2007-08-19 13:45:51 -06:00
extendedWord(Thread* t UNUSED, object o, unsigned baseSize)
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, objectExtended(t, o));
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
return fieldAtOffset<uintptr_t>(o, baseSize * BytesPerWord);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
inline unsigned
extendedSize(Thread* t, object o, unsigned baseSize)
{
return baseSize + objectExtended(t, o);
}
inline void
markHashTaken(Thread* t, object o)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, not objectExtended(t, o));
assertT(t, not objectFixed(t, o));
simplify heap.cpp by allocating segments pessimistically
2007-08-18 15:24:29 -06:00
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
ACQUIRE_RAW(t, t->m->heapLock);
implement fixed object support
2007-10-27 19:54:30 -06:00
work around GCC name mangling bug It seems that older versions of GCC (4.0 and older, at least) generate assembly files with duplicate symbols for function templates which differ only by the attributes of the templated types. Newer versions have no such problem, but we need to support both, hence the workaround in this commit of using a dedicated, non-template "alias" function where we previously used "cast<alias_t>".
2011-02-14 11:47:59 -07:00
alias(o, 0) |= HashTakenMark;
force major collection under low memory condition
2008-01-14 09:39:57 -07:00
t->m->heap->pad(o);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
inline uint32_t
takeHash(Thread*, object o)
{
return only non-negative values from takeHash Some broken code implicitly relies on System.identityHashCode always returning a non-negative number (e.g. old versions of com/sun/xml/bind/v2/util/CollisionCheckStack.hash).
2011-03-27 20:22:59 -06:00
// some broken code implicitly relies on System.identityHashCode
// always returning a non-negative number (e.g. old versions of
// com/sun/xml/bind/v2/util/CollisionCheckStack.hash), hence the "&
// 0x7FFFFFFF":
return (reinterpret_cast<uintptr_t>(o) / BytesPerWord) & 0x7FFFFFFF;
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
inline uint32_t
objectHash(Thread* t, object o)
{
if (objectExtended(t, o)) {
return extendedWord(t, o, baseSize(t, o, objectClass(t, o)));
} else {
revise signatures of mark() and set() to take a target object and offset instead of a target object reference, paving the way for immovable objects
2007-10-22 11:22:30 -06:00
if (not objectFixed(t, o)) {
markHashTaken(t, o);
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
return takeHash(t, o);
}
}
inline bool
objectEqual(Thread*, object a, object b)
{
return a == b;
}
inline uint32_t
byteArrayHash(Thread* t, object array)
{
return hash(&byteArrayBody(t, array, 0), byteArrayLength(t, array));
}
implement String.intern()
2007-07-28 18:02:32 -06:00
inline uint32_t
charArrayHash(Thread* t, object array)
{
return hash(&charArrayBody(t, array, 0), charArrayLength(t, array));
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
inline bool
byteArrayEqual(Thread* t, object a, object b)
{
return a == b or
((byteArrayLength(t, a) == byteArrayLength(t, b)) and
memcmp(&byteArrayBody(t, a, 0), &byteArrayBody(t, b, 0),
byteArrayLength(t, a)) == 0);
}
implement String.intern()
2007-07-28 18:02:32 -06:00
inline uint32_t
stringHash(Thread* t, object s)
{
bugfixes
2007-08-19 14:24:26 -06:00
if (stringHashCode(t, s) == 0 and stringLength(t, s)) {
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
object data = reinterpret_cast<object>(stringData(t, s));
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (objectClass(t, data) == type(t, GcByteArray::Type)) {
bugfixes
2007-08-14 19:14:55 -06:00
stringHashCode(t, s) = hash
(&byteArrayBody(t, data, stringOffset(t, s)), stringLength(t, s));
implement String.intern()
2007-07-28 18:02:32 -06:00
} else {
bugfixes
2007-08-14 19:14:55 -06:00
stringHashCode(t, s) = hash
(&charArrayBody(t, data, stringOffset(t, s)), stringLength(t, s));
implement String.intern()
2007-07-28 18:02:32 -06:00
}
}
return stringHashCode(t, s);
}
inline uint16_t
stringCharAt(Thread* t, object s, int i)
{
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
object data = reinterpret_cast<object>(stringData(t, s));
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (objectClass(t, data) == type(t, GcByteArray::Type)) {
respect string offset in stringCharAt
2009-06-06 16:36:07 -06:00
return byteArrayBody(t, data, stringOffset(t, s) + i);
implement String.intern()
2007-07-28 18:02:32 -06:00
} else {
respect string offset in stringCharAt
2009-06-06 16:36:07 -06:00
return charArrayBody(t, data, stringOffset(t, s) + i);
implement String.intern()
2007-07-28 18:02:32 -06:00
}
}
inline bool
stringEqual(Thread* t, object a, object b)
{
if (a == b) {
return true;
} else if (stringLength(t, a) == stringLength(t, b)) {
clean up bootstrap type generation to eliminate redundancy (broken)
2007-11-04 14:15:28 -07:00
for (unsigned i = 0; i < stringLength(t, a); ++i) {
implement String.intern()
2007-07-28 18:02:32 -06:00
if (stringCharAt(t, a, i) != stringCharAt(t, b, i)) {
return false;
}
}
return true;
} else {
return false;
}
}
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
inline uint32_t
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
methodHash(Thread* t, object mo)
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcMethod* method = cast<GcMethod>(t, mo);
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
return byteArrayHash(t, reinterpret_cast<object>(method->name()))
^ byteArrayHash(t, reinterpret_cast<object>(method->spec()));
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
inline bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
methodEqual(Thread* t, object ao, object bo)
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcMethod* a = cast<GcMethod>(t, ao);
GcMethod* b = cast<GcMethod>(t, bo);
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
return a == b or
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
(byteArrayEqual(t, reinterpret_cast<object>(a->name()), reinterpret_cast<object>(b->name())) and
byteArrayEqual(t, reinterpret_cast<object>(a->spec()), reinterpret_cast<object>(b->spec())));
factor a lot of code out of vm.cpp, since it was becoming unwieldy
2007-07-06 09:24:06 -06:00
}
sketch of Compiler.compileNative() and ifnull instruction implementation
2007-09-28 17:41:03 -06:00
class MethodSpecIterator {
public:
MethodSpecIterator(Thread* t, const char* s):
t(t), s(s + 1)
{ }
const char* next() {
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, *s != ')');
sketch of Compiler.compileNative() and ifnull instruction implementation
2007-09-28 17:41:03 -06:00
const char* p = s;
switch (*s) {
case 'L':
while (*s and *s != ';') ++ s;
++ s;
break;
case '[':
while (*s == '[') ++ s;
switch (*s) {
case 'L':
while (*s and *s != ';') ++ s;
++ s;
break;
default:
++ s;
break;
}
break;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
sketch of Compiler.compileNative() and ifnull instruction implementation
2007-09-28 17:41:03 -06:00
default:
++ s;
break;
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
sketch of Compiler.compileNative() and ifnull instruction implementation
2007-09-28 17:41:03 -06:00
return p;
}
bool hasNext() {
return *s != ')';
}
const char* returnSpec() {
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, *s == ')');
sketch of Compiler.compileNative() and ifnull instruction implementation
2007-09-28 17:41:03 -06:00
return s + 1;
}
Thread* t;
const char* s;
};
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
unsigned
fieldCode(Thread* t, unsigned javaCode);
unsigned
fieldType(Thread* t, unsigned code);
unsigned
primitiveSize(Thread* t, unsigned code);
inline unsigned
sketch of singleton support
2007-11-02 15:08:14 -06:00
fieldSize(Thread* t, unsigned code)
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
{
if (code == ObjectField) {
return BytesPerWord;
} else {
return primitiveSize(t, code);
}
}
sketch of singleton support
2007-11-02 15:08:14 -06:00
inline unsigned
fieldSize(Thread* t, object field)
{
return fieldSize(t, fieldCode(t, field));
}
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
inline void
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
scanMethodSpec(Thread* t, const char* s, bool static_,
unsigned* parameterCount, unsigned* parameterFootprint,
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
unsigned* returnCode)
{
unsigned count = 0;
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
unsigned footprint = 0;
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
MethodSpecIterator it(t, s);
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
while (it.hasNext()) {
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
++ count;
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
switch (*it.next()) {
case 'J':
case 'D':
footprint += 2;
break;
default:
++ footprint;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
break;
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
}
}
if (not static_) {
++ footprint;
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
}
*parameterCount = count;
add support for using the OpenJDK 8 class library This ensures that all tests pass when Avian is built with an openjdk=$path option such that $path points to either OpenJDK 7 or 8. Note that I have not yet tried using the openjdk-src option with OpenJDK 8. I'll work on that next.
2014-04-23 15:22:10 -06:00
*parameterFootprint = footprint;
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
*returnCode = fieldCode(t, *it.returnSpec());
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
findLoadedClass(Thread* t, GcClassLoader* loader, object spec);
flesh out ClassLoader, etc.
2007-07-30 17:19:05 -06:00
implement basic finalization support This implementation does not conform to the Java standard in that finalize methods are called from whichever thread happens to be garbage collecting, and that thread may hold locks, whereas the standard guarantees that finalize will be run from a thread which holds no locks. Also, an object will never be finalized more than once, even if its finalize method "rescues" (i.e. makes reachable) the object such that it might become unreachable a second time and thus a candidate for finalization once more. It's not clear to me from the standard if this is OK or not. Nonwithstanding the above, this implementation is useful for "normal" finalize methods which simply release resources associated with an object.
2009-07-21 18:57:55 -06:00
inline bool
add stronger typing to method.code
2014-06-27 22:00:05 -06:00
emptyMethod(Thread* t UNUSED, GcMethod* method)
implement basic finalization support This implementation does not conform to the Java standard in that finalize methods are called from whichever thread happens to be garbage collecting, and that thread may hold locks, whereas the standard guarantees that finalize will be run from a thread which holds no locks. Also, an object will never be finalized more than once, even if its finalize method "rescues" (i.e. makes reachable) the object such that it might become unreachable a second time and thus a candidate for finalization once more. It's not clear to me from the standard if this is OK or not. Nonwithstanding the above, this implementation is useful for "normal" finalize methods which simply release resources associated with an object.
2009-07-21 18:57:55 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return ((method->flags() & ACC_NATIVE) == 0)
add stronger typing to method.code
2014-06-27 22:00:05 -06:00
and (method->code()->length() == 1)
and (method->code()->body()[0] == return_);
implement basic finalization support This implementation does not conform to the Java standard in that finalize methods are called from whichever thread happens to be garbage collecting, and that thread may hold locks, whereas the standard guarantees that finalize will be run from a thread which holds no locks. Also, an object will never be finalized more than once, even if its finalize method "rescues" (i.e. makes reachable) the object such that it might become unreachable a second time and thus a candidate for finalization once more. It's not clear to me from the standard if this is OK or not. Nonwithstanding the above, this implementation is useful for "normal" finalize methods which simply release resources associated with an object.
2009-07-21 18:57:55 -06:00
}
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
object
parseUtf8(Thread* t, const char* data, unsigned length);
fix handling of classe, method, and field names with non-ASCII characters
2013-02-03 14:09:29 -07:00
object
parseUtf8(Thread* t, object array);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
parseClass(Thread* t, GcClassLoader* loader, const uint8_t* data, unsigned length,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
Gc::Type throwType = GcNoClassDefFoundError::Type);
flesh out ClassLoader, etc.
2007-07-30 17:19:05 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveClass(Thread* t, GcClassLoader* loader, object name, bool throw_ = true,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
Gc::Type throwType = GcNoClassDefFoundError::Type);
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveClass(Thread* t, GcClassLoader* loader, const char* name, bool throw_ = true,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
Gc::Type throwType = GcNoClassDefFoundError::Type)
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
{
add classloader parameter to functions which may directly or indirectly load classes; include methods inherited from interfaces (but not explicitly declared) in method tables and virtual tables of abstract classes
2009-08-10 07:56:16 -06:00
PROTECT(t, loader);
object n = makeByteArray(t, "%s", name);
various fixes and additions to increase app compatiblity The main changes here are: * fixes for runtime annotation support * proper support for runtime generic type introspection * throw NoClassDefFoundErrors instead of ClassNotFoundExceptions where appropriate
2011-03-17 21:42:15 -06:00
return resolveClass(t, loader, n, throw_, throwType);
add classloader parameter to functions which may directly or indirectly load classes; include methods inherited from interfaces (but not explicitly declared) in method tables and virtual tables of abstract classes
2009-08-10 07:56:16 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass*
various fixes and additions to increase app compatiblity The main changes here are: * fixes for runtime annotation support * proper support for runtime generic type introspection * throw NoClassDefFoundErrors instead of ClassNotFoundExceptions where appropriate
2011-03-17 21:42:15 -06:00
resolveSystemClass
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
(Thread* t, GcClassLoader* loader, object name, bool throw_ = true,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
Gc::Type throwType = GcNoClassDefFoundError::Type);
add classloader parameter to functions which may directly or indirectly load classes; include methods inherited from interfaces (but not explicitly declared) in method tables and virtual tables of abstract classes
2009-08-10 07:56:16 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveSystemClass(Thread* t, GcClassLoader* loader, const char* name)
add classloader parameter to functions which may directly or indirectly load classes; include methods inherited from interfaces (but not explicitly declared) in method tables and virtual tables of abstract classes
2009-08-10 07:56:16 -06:00
{
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
return resolveSystemClass(t, loader, makeByteArray(t, "%s", name));
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
}
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
void
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
linkClass(Thread* t, GcClassLoader* loader, GcClass* class_);
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcMethod*
resolveMethod(Thread* t, GcClass* class_, const char* methodName,
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
const char* methodSpec);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveMethod(Thread* t, GcClassLoader* loader, const char* className,
add classloader parameter to functions which may directly or indirectly load classes; include methods inherited from interfaces (but not explicitly declared) in method tables and virtual tables of abstract classes
2009-08-10 07:56:16 -06:00
const char* methodName, const char* methodSpec)
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
{
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
return resolveMethod
(t, resolveClass(t, loader, className), methodName, methodSpec);
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
}
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
resolveField(Thread* t, GcClass* class_, const char* fieldName,
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
const char* fieldSpec);
inline object
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveField(Thread* t, GcClassLoader* loader, const char* className,
add classloader parameter to functions which may directly or indirectly load classes; include methods inherited from interfaces (but not explicitly declared) in method tables and virtual tables of abstract classes
2009-08-10 07:56:16 -06:00
const char* fieldName, const char* fieldSpec)
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
{
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
return resolveField
(t, resolveClass(t, loader, className), fieldName, fieldSpec);
implement NewDirectByteBuffer etc. properly when building against Classpath; call JNI_OnLoad if found in newly-loaded libraries
2009-06-10 18:15:00 -06:00
}
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
classNeedsInit(Thread* t, GcClass* c);
fix static class initialization when using a boot image
2008-11-29 21:58:09 -07:00
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
preInitClass(Thread* t, GcClass* c);
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
postInitClass(Thread* t, GcClass* c);
fix deadlocks and other misbehaviors in class initialization code
2009-07-20 14:12:38 -06:00
void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
initClass(Thread* t, GcClass* c);
fix Method.invoke() to handle polymorphism properly
2007-08-22 21:30:37 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveObjectArrayClass(Thread* t, GcClassLoader* loader, object elementClass);
fix time==0 case in Unsafe.park and implement JVM_DumpThreads Also, set name field on system threads for OpenJDK build to avoid NPEs in Thread.getName.
2010-11-27 16:27:30 -07:00
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeObjectArray(Thread* t, GcClass* elementClass, unsigned count);
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
support runtime-visible annotations and java.lang.reflect.Proxy
2009-09-18 18:01:54 -06:00
inline object
makeObjectArray(Thread* t, unsigned count)
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return makeObjectArray(t, type(t, GcJobject::Type), count);
support runtime-visible annotations and java.lang.reflect.Proxy
2009-09-18 18:01:54 -06:00
}
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
findFieldInClass(Thread* t, GcClass* class_, object name, object spec);
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
findFieldInClass2(Thread* t, GcClass* class_, const char* name, const char* spec)
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
{
PROTECT(t, class_);
object n = makeByteArray(t, "%s", name);
PROTECT(t, n);
object s = makeByteArray(t, "%s", spec);
return findFieldInClass(t, class_, n, s);
}
make find[Field|Method]InClass non-inline functions It seems that GCC 4.6.1 gets confused at LTO time when we take the address of inline functions, so I'm switching them to non-inline linkage to make it happy.
2012-03-26 18:06:16 -06:00
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
findMethodInClass(Thread* t, GcClass* class_, object name, object spec);
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
inline object
makeThrowable
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
(Thread* t, Gc::Type type, object message = 0, object trace = 0,
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
object cause = 0)
{
PROTECT(t, message);
PROTECT(t, trace);
PROTECT(t, cause);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
if (trace == 0) {
trace = makeTrace(t);
}
object result = make(t, vm::type(t, type));
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
avoid inifinite recursion if java.lang.Object is missing; refactoring When trying to create an array class, we try to resolve java.lang.Object so we can use its vtable in the array class. However, if Object is missing, we'll try to create and throw a ClassNotFoundException, which requires creating an array to store the stack trace, which requires creating an array class, which requires resolving Object, etc.. This commit short-circuits this process by telling resolveClass not to create and throw an exception if it can't find Object. While doing the above work, I noticed that the implementations of Classpath::makeThrowable in classpath-avian.cpp and classpath-openjdk.cpp were identical, so I made makeThrowable a top-level function. Finally, I discovered that Thread.setDaemon can only be called before the target thread has been started, which allowed me to simplify the code to track daemon threads in the VM.
2010-12-09 19:38:12 -07:00
set(t, result, ThrowableMessage, message);
set(t, result, ThrowableTrace, trace);
set(t, result, ThrowableCause, cause);
return result;
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeThrowableV(Thread* t, Gc::Type type, const char* format, va_list a,
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
int size)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
object s = makeByteArrayV(t, format, a, size);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
if (s) {
object message = t->m->classpath->makeString
(t, s, 0, byteArrayLength(t, s) - 1);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
return makeThrowable(t, type, message);
} else {
return 0;
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
}
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
makeThrowable(Thread* t, Gc::Type type, const char* format, ...)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
int size = 256;
while (true) {
va_list a;
va_start(a, format);
object r = makeThrowableV(t, type, format, a, size);
va_end(a);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
if (r) {
return r;
} else {
size *= 2;
}
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
}
fix continuations=true build
2011-01-27 11:54:41 -07:00
void
popResources(Thread* t);
fix unintentionally retained finalizables and improve low mem performance Objects which are eligable for finalization must be retained until after their finalize methods are called. However, the VM must determine the entire set of such objects before retaining any of them; otherwise the process of retaining a given object may cause others to become reachable and thus be considered ineligible for finalization even though they are only reachable via other finalizable objects. The end result of this mistake is that only a few of the objects which are finalizable will be recognized at each GC cycle, so it requires many such cycles to find them all, and if new objects become finalizable at a faster rate, the VM will never catch up and eventually run out of memory. This patch fixes the above mistake and also includes tuning to minimize the need for GC in low memory situations.
2013-03-07 20:17:05 -07:00
} // namespace vm
rename JNIEXPORT to AVIAN_EXPORT in common.h, to avoid conflicting with jni.h
2013-11-08 08:35:10 -07:00
AVIAN_EXPORT void
fix unintentionally retained finalizables and improve low mem performance Objects which are eligable for finalization must be retained until after their finalize methods are called. However, the VM must determine the entire set of such objects before retaining any of them; otherwise the process of retaining a given object may cause others to become reachable and thus be considered ineligible for finalization even though they are only reachable via other finalizable objects. The end result of this mistake is that only a few of the objects which are finalizable will be recognized at each GC cycle, so it requires many such cycles to find them all, and if new objects become finalizable at a faster rate, the VM will never catch up and eventually run out of memory. This patch fixes the above mistake and also includes tuning to minimize the need for GC in low memory situations.
2013-03-07 20:17:05 -07:00
vmPrintTrace(vm::Thread* t);
rename JNIEXPORT to AVIAN_EXPORT in common.h, to avoid conflicting with jni.h
2013-11-08 08:35:10 -07:00
AVIAN_EXPORT void
add vmfPrintTrace method for dumping traces to a specific stream
2013-04-09 17:45:19 -06:00
vmfPrintTrace(vm::Thread* t, FILE* out);
fix unintentionally retained finalizables and improve low mem performance Objects which are eligable for finalization must be retained until after their finalize methods are called. However, the VM must determine the entire set of such objects before retaining any of them; otherwise the process of retaining a given object may cause others to become reachable and thus be considered ineligible for finalization even though they are only reachable via other finalizable objects. The end result of this mistake is that only a few of the objects which are finalizable will be recognized at each GC cycle, so it requires many such cycles to find them all, and if new objects become finalizable at a faster rate, the VM will never catch up and eventually run out of memory. This patch fixes the above mistake and also includes tuning to minimize the need for GC in low memory situations.
2013-03-07 20:17:05 -07:00
namespace vm {
void
dumpHeap(Thread* t, FILE* out);
fix continuations=true build
2011-01-27 11:54:41 -07:00
inline void NO_RETURN
throw_(Thread* t, object e)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, t->exception == 0);
assertT(t, e);
fix continuations=true build
2011-01-27 11:54:41 -07:00
expect(t, not t->checkpoint->noThrow);
t->exception = e;
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (objectClass(t, e) == type(t, GcOutOfMemoryError::Type)) {
fix unintentionally retained finalizables and improve low mem performance Objects which are eligable for finalization must be retained until after their finalize methods are called. However, the VM must determine the entire set of such objects before retaining any of them; otherwise the process of retaining a given object may cause others to become reachable and thus be considered ineligible for finalization even though they are only reachable via other finalizable objects. The end result of this mistake is that only a few of the objects which are finalizable will be recognized at each GC cycle, so it requires many such cycles to find them all, and if new objects become finalizable at a faster rate, the VM will never catch up and eventually run out of memory. This patch fixes the above mistake and also includes tuning to minimize the need for GC in low memory situations.
2013-03-07 20:17:05 -07:00
#ifdef AVIAN_HEAPDUMP
if (not t->m->dumpedHeapOnOOM) {
t->m->dumpedHeapOnOOM = true;
const char* path = findProperty(t, "avian.heap.dump");
if (path) {
FILE* out = vm::fopen(path, "wb");
if (out) {
dumpHeap(t, out);
fclose(out);
}
}
}
#endif//AVIAN_HEAPDUMP
if (AbortOnOutOfMemoryError) {
fprintf(stderr, "OutOfMemoryError\n");
vmPrintTrace(t);
abort();
}
}
fix various regressions due to 0.5 work
2011-02-11 21:13:11 -07:00
// printTrace(t, e);
fix continuations=true build
2011-01-27 11:54:41 -07:00
popResources(t);
t->checkpoint->unwind();
abort(t);
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
inline void NO_RETURN
fix various regressions due to 0.5 work
2011-02-11 21:13:11 -07:00
throwNew
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
(Thread* t, Gc::Type type, object message = 0, object trace = 0,
fix various regressions due to 0.5 work
2011-02-11 21:13:11 -07:00
object cause = 0)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
fix various regressions due to 0.5 work
2011-02-11 21:13:11 -07:00
throw_(t, makeThrowable(t, type, message, trace, cause));
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
}
inline void NO_RETURN
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
throwNew(Thread* t, Gc::Type type, const char* format, ...)
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
{
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
int size = 256;
while (true) {
va_list a;
va_start(a, format);
object r = makeThrowableV(t, type, format, a, size);
va_end(a);
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
fix recent throwNew/makeThrowable regression 6fceca9 introduced a string formatting regression in these methods, which this commit fixes.
2012-03-03 18:37:27 -07:00
if (r) {
throw_(t, r);
} else {
size *= 2;
}
}
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
}
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
findInHierarchyOrNull(Thread* t, GcClass* class_, object name, object spec,
object (*find)(Thread*, GcClass*, object, object));
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
findInHierarchy(Thread* t, GcClass* class_, object name, object spec,
object (*find)(Thread*, GcClass*, object, object),
Gc::Type errorType, bool throw_ = true)
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
{
object o = findInHierarchyOrNull(t, class_, name, spec, find);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
if (throw_ and o == 0) {
rework VM exception handling; throw OOMEs when appropriate This rather large commit modifies the VM to use non-local returns to throw exceptions instead of simply setting Thread::exception and returning frame-by-frame as it used to. This has several benefits: * Functions no longer need to check Thread::exception after each call which might throw an exception (which would be especially tedious and error-prone now that any function which allocates objects directly or indirectly might throw an OutOfMemoryError) * There's no need to audit the code for calls to functions which previously did not throw exceptions but later do * Performance should be improved slightly due to both the reduced need for conditionals and because undwinding now occurs in a single jump instead of a series of returns The main disadvantages are: * Slightly higher overhead for entering and leaving the VM via the JNI and JDK methods * Non-local returns can make the code harder to read * We must be careful to register destructors for stack-allocated resources with the Thread so they can be called prior to a non-local return The non-local return implementation is similar to setjmp/longjmp, except it uses continuation-passing style to avoid the need for cooperation from the C/C++ compiler. Native C++ exceptions would have also been an option, but that would introduce a dependence on libstdc++, which we're trying to avoid for portability reasons. Finally, this commit ensures that the VM throws an OutOfMemoryError instead of aborting when it reaches its memory ceiling. Currently, we treat the ceiling as a soft limit and temporarily exceed it as necessary to allow garbage collection and certain internal allocations to succeed, but refuse to allocate any Java objects until the heap size drops back below the ceiling.
2010-12-27 15:55:23 -07:00
throwNew(t, errorType, "%s %s not found in %s",
&byteArrayBody(t, name, 0),
&byteArrayBody(t, spec, 0),
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
class_->name()->body().begin());
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
}
return o;
}
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
findMethod(Thread* t, GcClass* class_, object name, object spec)
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcMethod>(t, findInHierarchy
(t, class_, name, spec, findMethodInClass, GcNoSuchMethodError::Type));
several things: change object typedef to Object* instead of void* to improve type safety; add JNICALL attributes to JNI functions; implement additional JavaVM methods
2007-09-06 18:21:52 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
findMethodOrNull(Thread* t, GcClass* class_, const char* name, const char* spec)
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
{
PROTECT(t, class_);
object n = makeByteArray(t, "%s", name);
PROTECT(t, n);
object s = makeByteArray(t, "%s", spec);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcMethod>(t, findInHierarchyOrNull(t, class_, n, s, findMethodInClass));
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
findVirtualMethod(Thread* t, GcMethod* method, GcClass* class_)
use virtual dispatch when calling Thread.run from VM
2008-06-25 10:28:11 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcMethod>(t, arrayBody(t, class_->virtualTable(), method->offset()));
use virtual dispatch when calling Thread.run from VM
2008-06-25 10:28:11 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
findInterfaceMethod(Thread* t, GcMethod* method, GcClass* class_)
support runtime-visible annotations and java.lang.reflect.Proxy
2009-09-18 18:01:54 -06:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, (class_->vmFlags() & BootstrapFlag) == 0);
support runtime-visible annotations and java.lang.reflect.Proxy
2009-09-18 18:01:54 -06:00
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
GcClass* interface = method->class_();
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
object itable = class_->interfaceTable();
support runtime-visible annotations and java.lang.reflect.Proxy
2009-09-18 18:01:54 -06:00
for (unsigned i = 0; i < arrayLength(t, itable); i += 2) {
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
if (arrayBody(t, itable, i) == reinterpret_cast<object>(interface)) {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcMethod>(t, arrayBody
(t, arrayBody(t, itable, i + 1), method->offset()));
support runtime-visible annotations and java.lang.reflect.Proxy
2009-09-18 18:01:54 -06:00
}
}
abort(t);
}
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
inline unsigned
various performance tweaks and bugfixes
2007-08-19 13:45:51 -06:00
objectArrayLength(Thread* t UNUSED, object array)
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, objectClass(t, array)->fixedSize() == BytesPerWord * 2);
assertT(t, objectClass(t, array)->arrayElementSize() == BytesPerWord);
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
return fieldAtOffset<uintptr_t>(array, BytesPerWord);
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
}
inline object&
various performance tweaks and bugfixes
2007-08-19 13:45:51 -06:00
objectArrayBody(Thread* t UNUSED, object array, unsigned index)
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, objectClass(t, array)->fixedSize() == BytesPerWord * 2);
assertT(t, objectClass(t, array)->arrayElementSize() == BytesPerWord);
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
assertT(t, reinterpret_cast<object>(objectClass(t, array)->objectMask())
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
== classObjectMask(t, arrayBody
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
(t, t->m->types, GcArray::Type)));
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
return fieldAtOffset<object>(array, ArrayBody + (index * BytesPerWord));
support object arrays of various element types and dimensions; clean up weak hash map support
2007-07-14 11:31:01 -06:00
}
handle weak maps properly in hashMapResize, hashMapRemove, etc.; move Processor::parameterFootprint() into machine.h/machine.cpp
2007-11-20 15:24:02 -07:00
unsigned
parameterFootprint(Thread* t, const char* s, bool static_);
more refactoring
2007-07-06 17:50:26 -06:00
void
addFinalizer(Thread* t, object target, void (*finalize)(Thread*, object));
fix race condition in monitorRelease There was an unlikely but dangerous race condition in monitorRelease such that when a thread released a monitor and then tried to notify the next thread in line, the latter thread might exit before it can be notified. This potentially led to a crash as the former thread tried to acquire and notify the latter thread's private lock after it had been disposed. The solution is to do as we do in the interrupt and join cases: call acquireSystem first and thereby either block the target thread from exiting until we're done or find that it has already exited, in which case nothing needs to be done. I also looked at monitorNotify to see if we have a similar bug there, but in that case the target thread can't exit without first acquiring and releasing the monitor, and since we ensure that no thread can execute monitorNotify without holding the monitor, there's no potential for a race.
2010-12-16 16:46:25 -07:00
inline bool
acquireSystem(Thread* t, Thread* target)
{
ACQUIRE_RAW(t, t->m->stateLock);
avoid running out of OS resources due to zombie thread accumulation (part 2) My previous attempt wasn't quite sufficient, since it was too late to call join on a thread which had already exited given the code was written to aggressively dispose of system handles as soon as the thread exited. The solution is to delay disposing these handles until after we're able to join the thread.
2012-02-03 17:20:20 -07:00
if (t->state != Thread::JoinedState) {
fix race condition in monitorRelease There was an unlikely but dangerous race condition in monitorRelease such that when a thread released a monitor and then tried to notify the next thread in line, the latter thread might exit before it can be notified. This potentially led to a crash as the former thread tried to acquire and notify the latter thread's private lock after it had been disposed. The solution is to do as we do in the interrupt and join cases: call acquireSystem first and thereby either block the target thread from exiting until we're done or find that it has already exited, in which case nothing needs to be done. I also looked at monitorNotify to see if we have a similar bug there, but in that case the target thread can't exit without first acquiring and releasing the monitor, and since we ensure that no thread can execute monitorNotify without holding the monitor, there's no potential for a race.
2010-12-16 16:46:25 -07:00
atomicOr(&(target->flags), Thread::SystemFlag);
return true;
} else {
return false;
}
}
inline void
releaseSystem(Thread* t, Thread* target)
{
ACQUIRE_RAW(t, t->m->stateLock);
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, t->state != Thread::JoinedState);
fix race condition in monitorRelease There was an unlikely but dangerous race condition in monitorRelease such that when a thread released a monitor and then tried to notify the next thread in line, the latter thread might exit before it can be notified. This potentially led to a crash as the former thread tried to acquire and notify the latter thread's private lock after it had been disposed. The solution is to do as we do in the interrupt and join cases: call acquireSystem first and thereby either block the target thread from exiting until we're done or find that it has already exited, in which case nothing needs to be done. I also looked at monitorNotify to see if we have a similar bug there, but in that case the target thread can't exit without first acquiring and releasing the monitor, and since we ensure that no thread can execute monitorNotify without holding the monitor, there's no potential for a race.
2010-12-16 16:46:25 -07:00
atomicAnd(&(target->flags), ~Thread::SystemFlag);
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
inline bool
atomicCompareAndSwapObject(Thread* t, object target, unsigned offset,
object old, object new_)
{
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
if (atomicCompareAndSwap(&fieldAtOffset<uintptr_t>(target, offset),
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
reinterpret_cast<uintptr_t>(old),
reinterpret_cast<uintptr_t>(new_)))
{
mark(t, target, offset);
return true;
} else {
return false;
}
}
// The following two methods (monitorAtomicAppendAcquire and
// monitorAtomicPollAcquire) use the Michael and Scott Non-Blocking
// Queue Algorithm: http://www.cs.rochester.edu/u/michael/PODC96.html
inline void
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
monitorAtomicAppendAcquire(Thread* t, object monitor, object node)
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
{
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
if (node == 0) {
PROTECT(t, monitor);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
node = reinterpret_cast<object>(makeMonitorNode(t, t, 0));
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
while (true) {
object tail = monitorAcquireTail(t, monitor);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
loadMemoryBarrier();
object next = monitorNodeNext(t, tail);
loadMemoryBarrier();
if (tail == monitorAcquireTail(t, monitor)) {
if (next) {
atomicCompareAndSwapObject
(t, monitor, MonitorAcquireTail, tail, next);
} else if (atomicCompareAndSwapObject
(t, tail, MonitorNodeNext, 0, node))
{
atomicCompareAndSwapObject
(t, monitor, MonitorAcquireTail, tail, node);
return;
}
}
}
}
inline Thread*
monitorAtomicPollAcquire(Thread* t, object monitor, bool remove)
{
while (true) {
object head = monitorAcquireHead(t, monitor);
loadMemoryBarrier();
object tail = monitorAcquireTail(t, monitor);
loadMemoryBarrier();
object next = monitorNodeNext(t, head);
loadMemoryBarrier();
if (head == monitorAcquireHead(t, monitor)) {
if (head == tail) {
if (next) {
atomicCompareAndSwapObject
(t, monitor, MonitorAcquireTail, tail, next);
} else {
return 0;
}
} else {
Thread* value = static_cast<Thread*>(monitorNodeValue(t, next));
if ((not remove)
or atomicCompareAndSwapObject
(t, monitor, MonitorAcquireHead, head, next))
{
return value;
}
}
}
}
}
inline bool
monitorTryAcquire(Thread* t, object monitor)
{
if (monitorOwner(t, monitor) == t
or (monitorAtomicPollAcquire(t, monitor, false) == 0
and atomicCompareAndSwap
(reinterpret_cast<uintptr_t*>(&monitorOwner(t, monitor)), 0,
reinterpret_cast<uintptr_t>(t))))
{
++ monitorDepth(t, monitor);
return true;
} else {
return false;
}
}
inline void
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
monitorAcquire(Thread* t, object monitor, object node = 0)
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
{
if (not monitorTryAcquire(t, monitor)) {
PROTECT(t, monitor);
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
PROTECT(t, node);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
ACQUIRE(t, t->lock);
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
monitorAtomicAppendAcquire(t, monitor, node);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
// note that we don't try to acquire the lock until we're first in
// line, both because it's fair and because we don't support
// removing elements from arbitrary positions in the queue
while (not (t == monitorAtomicPollAcquire(t, monitor, false)
and atomicCompareAndSwap
(reinterpret_cast<uintptr_t*>(&monitorOwner(t, monitor)), 0,
reinterpret_cast<uintptr_t>(t))))
{
ENTER(t, Thread::IdleState);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
t->lock->wait(t->systemThread, 0);
}
expect(t, t == monitorAtomicPollAcquire(t, monitor, true));
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
++ monitorDepth(t, monitor);
}
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorOwner(t, monitor) == t);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
}
inline void
monitorRelease(Thread* t, object monitor)
{
expect(t, monitorOwner(t, monitor) == t);
if (-- monitorDepth(t, monitor) == 0) {
monitorOwner(t, monitor) = 0;
storeLoadMemoryBarrier();
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
Thread* next = monitorAtomicPollAcquire(t, monitor, false);
fix race condition in monitorRelease There was an unlikely but dangerous race condition in monitorRelease such that when a thread released a monitor and then tried to notify the next thread in line, the latter thread might exit before it can be notified. This potentially led to a crash as the former thread tried to acquire and notify the latter thread's private lock after it had been disposed. The solution is to do as we do in the interrupt and join cases: call acquireSystem first and thereby either block the target thread from exiting until we're done or find that it has already exited, in which case nothing needs to be done. I also looked at monitorNotify to see if we have a similar bug there, but in that case the target thread can't exit without first acquiring and releasing the monitor, and since we ensure that no thread can execute monitorNotify without holding the monitor, there's no potential for a race.
2010-12-16 16:46:25 -07:00
if (next and acquireSystem(t, next)) {
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
ACQUIRE(t, next->lock);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
next->lock->notify(t->systemThread);
fix race condition in monitorRelease There was an unlikely but dangerous race condition in monitorRelease such that when a thread released a monitor and then tried to notify the next thread in line, the latter thread might exit before it can be notified. This potentially led to a crash as the former thread tried to acquire and notify the latter thread's private lock after it had been disposed. The solution is to do as we do in the interrupt and join cases: call acquireSystem first and thereby either block the target thread from exiting until we're done or find that it has already exited, in which case nothing needs to be done. I also looked at monitorNotify to see if we have a similar bug there, but in that case the target thread can't exit without first acquiring and releasing the monitor, and since we ensure that no thread can execute monitorNotify without holding the monitor, there's no potential for a race.
2010-12-16 16:46:25 -07:00
releaseSystem(t, next);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
}
}
}
inline void
monitorAppendWait(Thread* t, object monitor)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorOwner(t, monitor) == t);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
expect(t, (t->flags & Thread::WaitingFlag) == 0);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
expect(t, t->waitNext == 0);
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
atomicOr(&(t->flags), Thread::WaitingFlag);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
if (monitorWaitTail(t, monitor)) {
static_cast<Thread*>(monitorWaitTail(t, monitor))->waitNext = t;
} else {
monitorWaitHead(t, monitor) = t;
}
monitorWaitTail(t, monitor) = t;
}
inline void
monitorRemoveWait(Thread* t, object monitor)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorOwner(t, monitor) == t);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
Thread* previous = 0;
for (Thread* current = static_cast<Thread*>(monitorWaitHead(t, monitor));
current; current = current->waitNext)
{
if (t == current) {
if (t == monitorWaitHead(t, monitor)) {
monitorWaitHead(t, monitor) = t->waitNext;
} else {
previous->waitNext = t->waitNext;
}
if (t == monitorWaitTail(t, monitor)) {
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, t->waitNext == 0);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
monitorWaitTail(t, monitor) = previous;
}
t->waitNext = 0;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
atomicAnd(&(t->flags), ~Thread::WaitingFlag);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
return;
} else {
previous = current;
}
}
abort(t);
}
inline bool
monitorFindWait(Thread* t, object monitor)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorOwner(t, monitor) == t);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
for (Thread* current = static_cast<Thread*>(monitorWaitHead(t, monitor));
current; current = current->waitNext)
{
if (t == current) {
return true;
}
}
return false;
}
inline bool
monitorWait(Thread* t, object monitor, int64_t time)
{
expect(t, monitorOwner(t, monitor) == t);
bool interrupted;
unsigned depth;
PROTECT(t, monitor);
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
// pre-allocate monitor node so we don't get an OutOfMemoryError
// when we try to re-acquire the monitor below
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
object monitorNode = reinterpret_cast<object>(makeMonitorNode(t, t, 0));
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
PROTECT(t, monitorNode);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
{ ACQUIRE(t, t->lock);
monitorAppendWait(t, monitor);
depth = monitorDepth(t, monitor);
monitorDepth(t, monitor) = 1;
monitorRelease(t, monitor);
ENTER(t, Thread::IdleState);
add new System::Monitor::waitAndClearInterrupted method We had be using System::Monitor::wait to block threads internally in the VM as well as to implement Object.wait. However, the interrupted flag should only be cleared in the latter case, not the former. This commit adds a new method and changes the semantics of the old one in order to acheive the desired behavior.
2011-07-12 18:01:17 -06:00
interrupted = t->lock->waitAndClearInterrupted(t->systemThread, time);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
}
preallocate monitor node in monitorWait If we don't preallocate the memory we need to reacquire the lock after we finish waiting, we risk an OOME which may unwind the stack into code which assumes we still have acquire the lock successfully.
2011-03-25 18:21:15 -06:00
monitorAcquire(t, monitor, monitorNode);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
monitorDepth(t, monitor) = depth;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
if (t->flags & Thread::WaitingFlag) {
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
monitorRemoveWait(t, monitor);
} else {
expect(t, not monitorFindWait(t, monitor));
}
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorOwner(t, monitor) == t);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
return interrupted;
}
inline Thread*
monitorPollWait(Thread* t, object monitor)
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorOwner(t, monitor) == t);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
Thread* next = static_cast<Thread*>(monitorWaitHead(t, monitor));
if (next) {
monitorWaitHead(t, monitor) = next->waitNext;
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
atomicAnd(&(next->flags), ~Thread::WaitingFlag);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
next->waitNext = 0;
if (next == monitorWaitTail(t, monitor)) {
monitorWaitTail(t, monitor) = 0;
}
} else {
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, monitorWaitTail(t, monitor) == 0);
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
}
return next;
}
inline bool
monitorNotify(Thread* t, object monitor)
{
expect(t, monitorOwner(t, monitor) == t);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
Thread* next = monitorPollWait(t, monitor);
if (next) {
ACQUIRE(t, next->lock);
next->lock->notify(t->systemThread);
return true;
} else {
return false;
}
}
inline void
monitorNotifyAll(Thread* t, object monitor)
{
PROTECT(t, monitor);
while (monitorNotify(t, monitor)) { }
}
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
class ObjectMonitorResource {
public:
ObjectMonitorResource(Thread* t, object o): o(o), protector(t, &(this->o)) {
monitorAcquire(protector.t, o);
}
~ObjectMonitorResource() {
monitorRelease(protector.t, o);
}
private:
object o;
Thread::SingleProtector protector;
};
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
object
various threading bugfixes
2007-11-27 15:23:00 -07:00
objectMonitor(Thread* t, object o, bool createNew);
more refactoring
2007-07-06 17:50:26 -06:00
bugfixes
2007-07-07 17:47:35 -06:00
inline void
acquire(Thread* t, object o)
{
fix subtle bug in hashMapInsert which caused us to update the old array previously associated with the hash map, whereas a GC causes the table to be resized when a weak reference is removed and thus a new array used
2008-01-19 13:12:16 -07:00
unsigned hash;
if (DebugMonitors) {
hash = objectHash(t, o);
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
object m = objectMonitor(t, o, true);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
if (DebugMonitors) {
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
fprintf(stderr, "thread %p acquires %p for %x\n", t, m, hash);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
monitorAcquire(t, m);
bugfixes
2007-07-07 17:47:35 -06:00
}
inline void
release(Thread* t, object o)
{
fix subtle bug in hashMapInsert which caused us to update the old array previously associated with the hash map, whereas a GC causes the table to be resized when a weak reference is removed and thus a new array used
2008-01-19 13:12:16 -07:00
unsigned hash;
if (DebugMonitors) {
hash = objectHash(t, o);
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
object m = objectMonitor(t, o, false);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
if (DebugMonitors) {
fix custom-classloader-related concurrency problems and other bugs The main changes in this commit ensure that we don't hold the global class lock when doing class resolution using application-defined classloaders. Such classloaders may do their own locking (in fact, it's almost certain), making deadlock likely when mixed with VM-level locking in various orders. Other changes include a fix to avoid overflow when waiting for extremely long intervals and a GC root stack mapping bug.
2010-09-16 19:43:27 -06:00
fprintf(stderr, "thread %p releases %p for %x\n", t, m, hash);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
monitorRelease(t, m);
bugfixes
2007-07-07 17:47:35 -06:00
}
inline void
wait(Thread* t, object o, int64_t milliseconds)
{
fix subtle bug in hashMapInsert which caused us to update the old array previously associated with the hash map, whereas a GC causes the table to be resized when a weak reference is removed and thus a new array used
2008-01-19 13:12:16 -07:00
unsigned hash;
if (DebugMonitors) {
hash = objectHash(t, o);
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
object m = objectMonitor(t, o, false);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
if (DebugMonitors) {
support darwin/x86_64
2009-10-14 10:01:37 -06:00
fprintf(stderr, "thread %p waits %d millis on %p for %x\n",
t, static_cast<int>(milliseconds), m, hash);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
if (m and monitorOwner(t, m) == t) {
PROTECT(t, m);
bool interrupted = monitorWait(t, m, milliseconds);
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
if (interrupted) {
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
if (t->m->alive or (t->flags & Thread::DaemonFlag) == 0) {
set Thread.interrupted to true if thread is interrupted outside wait or sleep This is the correct behavior according to the Thread.interrupt JavaDoc, and it fixes an intermittent hang on exit in Eclipse.
2012-05-02 11:41:36 -06:00
t->m->classpath->clearInterrupted(t);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
throwNew(t, GcInterruptedException::Type);
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
} else {
throw_(t, root(t, Machine::Shutdown));
}
implement Thread.interrupt()
2007-07-28 15:28:25 -06:00
}
bugfixes
2007-07-07 17:47:35 -06:00
} else {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
throwNew(t, GcIllegalMonitorStateException::Type);
bugfixes
2007-07-07 17:47:35 -06:00
}
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
if (DebugMonitors) {
fprintf(stderr, "thread %p wakes up on %p for %x\n",
fix subtle bug in hashMapInsert which caused us to update the old array previously associated with the hash map, whereas a GC causes the table to be resized when a weak reference is removed and thus a new array used
2008-01-19 13:12:16 -07:00
t, m, hash);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
}
GC stress fixes
2007-07-19 17:45:44 -06:00
stress(t);
bugfixes
2007-07-07 17:47:35 -06:00
}
inline void
notify(Thread* t, object o)
{
fix subtle bug in hashMapInsert which caused us to update the old array previously associated with the hash map, whereas a GC causes the table to be resized when a weak reference is removed and thus a new array used
2008-01-19 13:12:16 -07:00
unsigned hash;
if (DebugMonitors) {
hash = objectHash(t, o);
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
object m = objectMonitor(t, o, false);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
if (DebugMonitors) {
fprintf(stderr, "thread %p notifies on %p for %x\n",
fix subtle bug in hashMapInsert which caused us to update the old array previously associated with the hash map, whereas a GC causes the table to be resized when a weak reference is removed and thus a new array used
2008-01-19 13:12:16 -07:00
t, m, hash);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
if (m and monitorOwner(t, m) == t) {
monitorNotify(t, m);
bugfixes
2007-07-07 17:47:35 -06:00
} else {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
throwNew(t, GcIllegalMonitorStateException::Type);
bugfixes
2007-07-07 17:47:35 -06:00
}
}
inline void
notifyAll(Thread* t, object o)
{
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
object m = objectMonitor(t, o, false);
more bugfixes, mainly monitor-related
2007-07-10 22:19:26 -06:00
if (DebugMonitors) {
fprintf(stderr, "thread %p notifies all on %p for %x\n",
t, m, objectHash(t, o));
}
reimplement Java object monitors (second try) See commit 8120bee4dc5f9ae2dec75a907778f1479ad398bd for the original problem description and solution. That commit and a couple of related ones had to be reverted when we found they had introduced GC-safety regressions leading to crashes. This commit restores the reverted code and fixes the regressions.
2010-02-04 17:56:21 -07:00
if (m and monitorOwner(t, m) == t) {
monitorNotifyAll(t, m);
bugfixes
2007-07-07 17:47:35 -06:00
} else {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
throwNew(t, GcIllegalMonitorStateException::Type);
bugfixes
2007-07-07 17:47:35 -06:00
}
}
fix race condition in interrupting/joining threads as they are exiting My recent commit to ensure that OS resources are released immediately upon thread exit introduced a race condition where interrupting or joining a thread as it exited could lead to attempts to use already-released resources. This commit adds locking to avoid the race.
2010-11-16 10:50:19 -07:00
inline void
interrupt(Thread* t, Thread* target)
{
if (acquireSystem(t, target)) {
clean up OS resources immediately upon thread exit Previously, we waited until the next GC to do this, but that can be too long for workloads which create a lot of short-lived threads but don't do much allocation.
2010-11-09 15:46:16 -07:00
target->systemThread->interrupt();
fix race condition in interrupting/joining threads as they are exiting My recent commit to ensure that OS resources are released immediately upon thread exit introduced a race condition where interrupting or joining a thread as it exited could lead to attempts to use already-released resources. This commit adds locking to avoid the race.
2010-11-16 10:50:19 -07:00
releaseSystem(t, target);
clean up OS resources immediately upon thread exit Previously, we waited until the next GC to do this, but that can be too long for workloads which create a lot of short-lived threads but don't do much allocation.
2010-11-09 15:46:16 -07:00
}
factor system.cpp and class-finder.cpp out of main.cpp
2007-07-20 08:36:31 -06:00
}
fix Thread.interrupt and Thread.interrupted These were both totally broken; the latter wasn't even implemented. This commit fixes/implements them and adds a simple test to exercise them.
2011-07-12 14:15:43 -06:00
inline bool
getAndClearInterrupted(Thread* t, Thread* target)
{
if (acquireSystem(t, target)) {
bool result = target->systemThread->getAndClearInterrupted();
releaseSystem(t, target);
return result;
} else {
return false;
}
}
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
inline bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
exceptionMatch(Thread* t, GcClass* type, object exception)
support multiple sequential VM instances with bootimage build Until now, the bootimage build hasn't supported using the Java invocation API to create a VM, destroy it, and create another in the same process. Ideally, we would be able to create multiple VMs simultaneously without any interference between them. In fact, Avian is designed to support this for the most part, but there are a few places we use global, mutable state which prevent this from working. Most notably, the bootimage is modified in-place at runtime, so the best we can do without extensive changes is to clean up the bootimage when the VM is destroyed so it's ready for later instances. Hence this commit. Ultimately, we can move towards a fully reentrant VM by making the bootimage immutable, but this will require some care to avoid performance regressions. Another challenge is our Posix signal handlers, which currently rely on a global handle to the VM, since you can't, to my knowledge, pass a context pointer when registering a signal handler. Thread local variables won't necessarily help, since a thread might attatch to more than one VM at a time.
2011-11-10 13:10:53 -07:00
{
return type == 0
or (exception != root(t, Machine::Shutdown)
and instanceOf(t, type, t->exception));
}
implement String.intern()
2007-07-28 18:02:32 -06:00
object
intern(Thread* t, object s);
initial work to support boot image creation and use
2008-11-21 16:20:35 -07:00
void
walk(Thread* t, Heap::Walker* w, object o, unsigned start);
Merge branch 'master' into powerpc Conflicts: makefile src/assembler.h src/compile.cpp src/compiler.cpp src/compiler.h src/finder.cpp
2008-11-11 08:20:49 -07:00
int
walkNext(Thread* t, object o, int previous);
void
visitRoots(Machine* m, Heap::Visitor* v);
bugfixes for recent refactoring effort
2007-09-24 07:46:48 -06:00
inline jobject
makeLocalReference(Thread* t, object o)
{
return t->m->processor->makeLocalReference(t, o);
}
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
bugfixes for recent refactoring effort
2007-09-24 07:46:48 -06:00
inline void
disposeLocalReference(Thread* t, jobject r)
{
t->m->processor->disposeLocalReference(t, r);
}
refactoring effort to pave the way for JIT compilation
2007-09-23 19:39:03 -06:00
snapshot
2007-11-05 07:28:46 -07:00
inline bool
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
methodVirtual(Thread* t UNUSED, GcMethod* method)
snapshot
2007-11-05 07:28:46 -07:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return (method->flags() & (ACC_STATIC | ACC_PRIVATE)) == 0
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
and method->name()->body()[0] != '<';
snapshot
2007-11-05 07:28:46 -07:00
}
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
inline unsigned
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
singletonMaskSize(unsigned count, unsigned bitsPerWord)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
if (count) {
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
return ceilingDivide(count + 2, bitsPerWord);
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
}
return 0;
}
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
inline unsigned
singletonMaskSize(unsigned count)
{
return singletonMaskSize(count, BitsPerWord);
}
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
inline unsigned
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonMaskSize(Thread* t UNUSED, GcSingleton* singleton)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
unsigned length = singleton->length();
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
if (length) {
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
return ceilingDivide(length + 2, BitsPerWord + 1);
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
}
return 0;
}
inline unsigned
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonCount(Thread* t, GcSingleton* singleton)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return singleton->length() - singletonMaskSize(t, singleton);
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
}
inline uint32_t*
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonMask(Thread* t, GcSingleton* singleton)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, singleton->length());
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
return reinterpret_cast<uint32_t*>
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
(&singletonBody(t, reinterpret_cast<object>(singleton), singletonCount(t, singleton)));
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
}
inline void
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
singletonMarkObject(uint32_t* mask, unsigned index)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
mask[(index + 2) / 32]
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
|= (static_cast<uint32_t>(1) << ((index + 2) % 32));
}
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
inline void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonMarkObject(Thread* t, GcSingleton* singleton, unsigned index)
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
{
singletonMarkObject(singletonMask(t, singleton), index);
}
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
inline bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonIsObject(Thread* t, GcSingleton* singleton, unsigned index)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, index < singletonCount(t, singleton));
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
return (singletonMask(t, singleton)[(index + 2) / 32]
& (static_cast<uint32_t>(1) << ((index + 2) % 32))) != 0;
}
minor tweaks to reduce memory usage
2007-11-06 08:29:05 -07:00
inline object&
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonObject(Thread* t, GcSingleton* singleton, unsigned index)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, singletonIsObject(t, singleton, index));
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return reinterpret_cast<object&>(singletonBody(t, reinterpret_cast<object>(singleton), index));
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
}
inline uintptr_t&
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonValue(Thread* t, GcSingleton* singleton, unsigned index)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, not singletonIsObject(t, singleton, index));
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return singletonBody(t, reinterpret_cast<object>(singleton), index);
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcSingleton*
zero heap space ahead of time when allocating raw storage and garbage collecting, not when allocating individual objects This helps us support the Java Memory Model without adding a memory barrier to every object allocation. It's also potentially more efficient, since we zero out each heap segment all at once instead of bit-by-bit with each object allocation.
2009-03-03 20:05:48 -07:00
makeSingletonOfSize(Thread* t, unsigned count)
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcSingleton* o = makeSingleton(t, count + singletonMaskSize(count));
rename assert to assertT, to avoid conflict with std assert macro
2014-06-03 19:52:01 -06:00
assertT(t, o->length() == count + singletonMaskSize(t, o));
finish support for inline vtables in class objects; convert constant pools from arrays to singletons to reduce memory footprint
2007-11-05 14:40:17 -07:00
if (count) {
singletonMask(t, o)[0] = 1;
}
return o;
}
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
inline void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonSetBit(Thread* t, GcSingleton* singleton, unsigned start, unsigned index)
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
{
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
singletonValue(t, singleton, start + (index / BitsPerWord))
|= static_cast<uintptr_t>(1) << (index % BitsPerWord);
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
}
inline bool
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
singletonBit(Thread* t, GcSingleton* singleton, unsigned start, unsigned index)
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
{
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
return (singletonValue(t, singleton, start + (index / BitsPerWord))
& (static_cast<uintptr_t>(1) << (index % BitsPerWord))) != 0;
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
}
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
inline unsigned
poolMaskSize(unsigned count, unsigned bitsPerWord)
{
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
return ceilingDivide(count, bitsPerWord);
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
}
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
inline unsigned
poolMaskSize(unsigned count)
{
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
return poolMaskSize(count, BitsPerWord);
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
}
inline unsigned
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
poolMaskSize(Thread* t, GcSingleton* pool)
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
{
rename ceiling -> ceilingDivide
2013-02-10 18:06:15 -07:00
return ceilingDivide(singletonCount(t, pool), BitsPerWord + 1);
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
}
inline unsigned
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
poolSize(Thread* t, GcSingleton* pool)
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
{
clean up float-vs.-int tracking in constant pools
2009-10-17 20:11:03 -06:00
return singletonCount(t, pool) - poolMaskSize(t, pool);
Merge branch 'master' of git://oss.readytalk.com/avian, fixed problems that occured in broader testing Conflicts: src/compile.cpp src/compiler.cpp src/powerpc.cpp src/x86.S src/x86.cpp
2009-08-10 13:20:23 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveClassInObject(Thread* t, GcClassLoader* loader, object container,
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
unsigned classOffset, bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
rename cast -> fieldAtOffset
2013-02-10 17:38:51 -07:00
object o = fieldAtOffset<object>(container, classOffset);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
loadMemoryBarrier();
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (objectClass(t, o) == type(t, GcByteArray::Type)) {
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
PROTECT(t, container);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass* c = resolveClass(t, loader, o, throw_);
if (c) {
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
storeStoreMemoryBarrier();
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
set(t, container, classOffset, reinterpret_cast<object>(c));
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return c;
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcClass>(t, o);
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveClassInPool(Thread* t, GcClassLoader* loader, GcMethod* method, unsigned index,
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
add stronger typing to method.code
2014-06-27 22:00:05 -06:00
object o = singletonObject(t, method->code()->pool(), index);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
loadMemoryBarrier();
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (objectClass(t, o) == type(t, GcReference::Type)) {
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
PROTECT(t, method);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass* c = resolveClass(t, loader, referenceName(t, o), throw_);
if (c) {
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
storeStoreMemoryBarrier();
add stronger typing to method.code
2014-06-27 22:00:05 -06:00
set(t, reinterpret_cast<object>(method->code()->pool()),
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
SingletonBody + (index * BytesPerWord), reinterpret_cast<object>(c));
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return c;
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcClass>(t, o);
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
resolveClassInPool(Thread* t, GcMethod* method, unsigned index,
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
return resolveClassInPool(t, method->class_()->loader(),
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
method, index, throw_);
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
inline object
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolve(Thread* t, GcClassLoader* loader, GcMethod* method, unsigned index,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
object (*find)(vm::Thread*, GcClass*, object, object),
Gc::Type errorType, bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
add stronger typing to method.code
2014-06-27 22:00:05 -06:00
object o = singletonObject(t, method->code()->pool(), index);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
loadMemoryBarrier();
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (objectClass(t, o) == type(t, GcReference::Type)) {
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
PROTECT(t, method);
object reference = o;
PROTECT(t, reference);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcClass* class_ = resolveClassInObject(t, loader, o, ReferenceClass, throw_);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
if (class_) {
o = findInHierarchy
(t, class_, referenceName(t, reference), referenceSpec(t, reference),
find, errorType, throw_);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
if (o) {
storeStoreMemoryBarrier();
add stronger typing to method.code
2014-06-27 22:00:05 -06:00
set(t, reinterpret_cast<object>(method->code()->pool()),
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
SingletonBody + (index * BytesPerWord), o);
}
} else {
o = 0;
}
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
return o;
}
inline object
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveField(Thread* t, GcClassLoader* loader, GcMethod* method, unsigned index,
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
return resolve(t, loader, method, index, findFieldInClass,
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcNoSuchFieldError::Type, throw_);
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
resolveField(Thread* t, GcMethod* method, unsigned index, bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
return resolveField
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
(t, method->class_()->loader(), method, index, throw_);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
}
inline void
acquireFieldForRead(Thread* t, object field)
{
if (UNLIKELY((fieldFlags(t, field) & ACC_VOLATILE)
and BytesPerWord == 4
and (fieldCode(t, field) == DoubleField
or fieldCode(t, field) == LongField)))
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
acquire(t, field);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
}
}
inline void
releaseFieldForRead(Thread* t, object field)
{
if (UNLIKELY(fieldFlags(t, field) & ACC_VOLATILE)) {
if (BytesPerWord == 4
and (fieldCode(t, field) == DoubleField
or fieldCode(t, field) == LongField))
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
release(t, field);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
} else {
loadMemoryBarrier();
}
}
}
class FieldReadResource {
public:
FieldReadResource(Thread* t, object o): o(o), protector(t, &(this->o)) {
acquireFieldForRead(protector.t, o);
}
~FieldReadResource() {
releaseFieldForRead(protector.t, o);
}
private:
object o;
Thread::SingleProtector protector;
};
inline void
acquireFieldForWrite(Thread* t, object field)
{
if (UNLIKELY(fieldFlags(t, field) & ACC_VOLATILE)) {
if (BytesPerWord == 4
and (fieldCode(t, field) == DoubleField
or fieldCode(t, field) == LongField))
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
acquire(t, field);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
} else {
storeStoreMemoryBarrier();
}
}
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
inline void
releaseFieldForWrite(Thread* t, object field)
{
if (UNLIKELY(fieldFlags(t, field) & ACC_VOLATILE)) {
if (BytesPerWord == 4
and (fieldCode(t, field) == DoubleField
or fieldCode(t, field) == LongField))
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
release(t, field);
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
} else {
storeLoadMemoryBarrier();
}
}
}
class FieldWriteResource {
public:
FieldWriteResource(Thread* t, object o): o(o), protector(t, &(this->o)) {
acquireFieldForWrite(protector.t, o);
}
~FieldWriteResource() {
releaseFieldForWrite(protector.t, o);
}
private:
object o;
Thread::SingleProtector protector;
};
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
resolveMethod(Thread* t, GcClassLoader* loader, GcMethod* method, unsigned index,
implement lazy class/field/method resolution in JIT compiler Unlike the interpreter, the JIT compiler tries to resolve all the symbols referenced by a method when compiling that method. However, this can backfire if a symbol cannot be resolved: we end up throwing an e.g. NoClassDefFoundError for code which may never be executed. This is particularly troublesome for code which supports multiple APIs, choosing one at runtime. The solution is to defer to stub code for symbols which can't be resolved at JIT compile time. Such a stub will try again at runtime to resolve the needed symbol and throw an appropriate error if it still can't be found.
2011-03-15 17:52:02 -06:00
bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
return cast<GcMethod>(t, resolve(t, loader, method, index, findMethodInClass,
GcNoSuchMethodError::Type, throw_));
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
resolveMethod(Thread* t, GcMethod* method, unsigned index, bool throw_ = true)
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
{
return resolveMethod
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
(t, method->class_()->loader(), method, index, throw_);
implement ClassLoader.resolveClass and ensure class is linked in e.g. Class.getMethods; minor bugfixes
2009-08-18 14:26:28 -06:00
}
add util.cpp/.h changes
2014-06-28 14:41:27 -06:00
GcVector*
vectorAppend(Thread*, GcVector*, object);
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
various fixes to get Eclipse 3.6 working * add libnet.so and libnio.so to built-in libraries for openjdk-src build * implement sun.misc.Unsafe.park/unpark * implement JVM_SetClassSigners/JVM_GetClassSigners * etc.
2010-11-27 11:25:02 -07:00
inline object
getClassRuntimeDataIfExists(Thread* t, object c)
{
if (classRuntimeDataIndex(t, c)) {
return vectorBody(t, root(t, Machine::ClassRuntimeDataTable),
classRuntimeDataIndex(t, c) - 1);
} else {
return 0;
}
}
break each Class, Field, and Method into separate classes In order to facilitate making the VM compatible with multiple class libraries, it's useful to separate the VM-specific representation of these classes from the library implementations. This commit introduces VMClass, VMField, and VMMethod for that purpose.
2010-09-01 10:13:52 -06:00
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
getClassRuntimeData(Thread* t, GcClass* c)
break each Class, Field, and Method into separate classes In order to facilitate making the VM compatible with multiple class libraries, it's useful to separate the VM-specific representation of these classes from the library implementations. This commit introduces VMClass, VMField, and VMMethod for that purpose.
2010-09-01 10:13:52 -06:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (c->runtimeDataIndex() == 0) {
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
PROTECT(t, c);
break each Class, Field, and Method into separate classes In order to facilitate making the VM compatible with multiple class libraries, it's useful to separate the VM-specific representation of these classes from the library implementations. This commit introduces VMClass, VMField, and VMMethod for that purpose.
2010-09-01 10:13:52 -06:00
ACQUIRE(t, t->m->classLock);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (c->runtimeDataIndex() == 0) {
object runtimeData = reinterpret_cast<object>(makeClassRuntimeData(t, 0, 0, 0, 0));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
add util.cpp/.h changes
2014-06-28 14:41:27 -06:00
setRoot(t, Machine::ClassRuntimeDataTable, reinterpret_cast<object>(vectorAppend
(t, cast<GcVector>(t, root(t, Machine::ClassRuntimeDataTable)), runtimeData)));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
c->runtimeDataIndex() = vectorSize
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
(t, root(t, Machine::ClassRuntimeDataTable));
}
break each Class, Field, and Method into separate classes In order to facilitate making the VM compatible with multiple class libraries, it's useful to separate the VM-specific representation of these classes from the library implementations. This commit introduces VMClass, VMField, and VMMethod for that purpose.
2010-09-01 10:13:52 -06:00
}
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
return vectorBody(t, root(t, Machine::ClassRuntimeDataTable),
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
c->runtimeDataIndex() - 1);
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
}
inline object
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
getMethodRuntimeData(Thread* t, GcMethod* method)
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
{
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
int index = method->runtimeDataIndex();
add appropriate memory barriers to double-checked locking code
2011-04-10 14:46:53 -06:00
loadMemoryBarrier();
if (index == 0) {
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
PROTECT(t, method);
ACQUIRE(t, t->m->classLock);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
if (method->runtimeDataIndex() == 0) {
object runtimeData = reinterpret_cast<object>(makeMethodRuntimeData(t, 0));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
add util.cpp/.h changes
2014-06-28 14:41:27 -06:00
setRoot(t, Machine::MethodRuntimeDataTable, reinterpret_cast<object>(vectorAppend
(t, cast<GcVector>(t, root(t, Machine::MethodRuntimeDataTable)), runtimeData)));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
add appropriate memory barriers to double-checked locking code
2011-04-10 14:46:53 -06:00
storeStoreMemoryBarrier();
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
method->runtimeDataIndex() = vectorSize
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
(t, root(t, Machine::MethodRuntimeDataTable));
}
}
return vectorBody(t, root(t, Machine::MethodRuntimeDataTable),
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
method->runtimeDataIndex() - 1);
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
}
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
inline GcJclass*
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
getJClass(Thread* t, GcClass* c)
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
{
fix GC safety bugs
2010-12-09 22:17:57 -07:00
PROTECT(t, c);
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
GcJclass* jclass = cast<GcJclass>(t, classRuntimeDataJclass(t, getClassRuntimeData(t, c)));
add appropriate memory barriers to double-checked locking code
2011-04-10 14:46:53 -06:00
loadMemoryBarrier();
break each Class, Field, and Method into separate classes In order to facilitate making the VM compatible with multiple class libraries, it's useful to separate the VM-specific representation of these classes from the library implementations. This commit introduces VMClass, VMField, and VMMethod for that purpose.
2010-09-01 10:13:52 -06:00
if (jclass == 0) {
ACQUIRE(t, t->m->classLock);
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
jclass = cast<GcJclass>(t, classRuntimeDataJclass(t, getClassRuntimeData(t, c)));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
if (jclass == 0) {
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
jclass = cast<GcJclass>(t, t->m->classpath->makeJclass(t, c));
add appropriate memory barriers to double-checked locking code
2011-04-10 14:46:53 -06:00
storeStoreMemoryBarrier();
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
generate better typed accessors from type-generator (and switch to using standard library there)
2014-06-20 22:16:33 -06:00
set(t, getClassRuntimeData(t, c), ClassRuntimeDataJclass, reinterpret_cast<object>(jclass));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
}
break each Class, Field, and Method into separate classes In order to facilitate making the VM compatible with multiple class libraries, it's useful to separate the VM-specific representation of these classes from the library implementations. This commit introduces VMClass, VMField, and VMMethod for that purpose.
2010-09-01 10:13:52 -06:00
}
return jclass;
}
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcClass*
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
primitiveClass(Thread* t, char name)
{
switch (name) {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
case 'B': return type(t, GcJbyte::Type);
case 'C': return type(t, GcJchar::Type);
case 'D': return type(t, GcJdouble::Type);
case 'F': return type(t, GcJfloat::Type);
case 'I': return type(t, GcJint::Type);
case 'J': return type(t, GcJlong::Type);
case 'S': return type(t, GcJshort::Type);
case 'V': return type(t, GcJvoid::Type);
case 'Z': return type(t, GcJboolean::Type);
default: throwNew(t, GcIllegalArgumentException::Type);
}
}
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
inline void
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
registerNative(Thread* t, GcMethod* method, void* function)
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
{
PROTECT(t, method);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
expect(t, method->flags() & ACC_NATIVE);
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
object native = reinterpret_cast<object>(makeNative(t, function, false));
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
PROTECT(t, native);
object runtimeData = getMethodRuntimeData(t, method);
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
// ensure other threads only see the methodRuntimeDataNative field
// populated once the object it points to has been populated:
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
storeStoreMemoryBarrier();
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
set(t, runtimeData, MethodRuntimeDataNative, native);
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
}
inline void
cache array class lookups in element class; misc. bugfixes
2010-09-25 15:54:01 -06:00
unregisterNatives(Thread* t, object c)
{
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
if (classMethodTable(t, c)) {
for (unsigned i = 0; i < arrayLength(t, classMethodTable(t, c)); ++i) {
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcMethod* method = cast<GcMethod>(t, arrayBody(t, classMethodTable(t, c), i));
if (method->flags() & ACC_NATIVE) {
fix openjdk-src bootimage build The main change here is to use a lazily-populated vector to associate runtime data with classes instead of referencing them directly from the class which requires updating immutable references in the heap image. The other changes employ other strategies to avoid trying to update immutable references.
2010-11-26 12:41:31 -07:00
set(t, getMethodRuntimeData(t, method), MethodRuntimeDataNative, 0);
more work towards OpenJDK classpath support The biggest change in this commit is to split the system classloader into two: one for boot classes (e.g. java.lang.*) and another for application classes. This is necessary to make OpenJDK's security checks happy. The rest of the changes include bugfixes and additional JVM method implementations in classpath-openjdk.cpp.
2010-09-14 10:49:41 -06:00
}
}
}
}
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
implement various JVM_* methods This includes a proper implementation of JVM_ActiveProcessorCount, as well as JVM_SetLength and JVM_NewMultiArray. Also, we now accept up to JNI_VERSION_1_6 in JVM_IsSupportedJNIVersion.
2011-03-26 11:15:52 -06:00
void
populateMultiArray(Thread* t, object array, int32_t* counts,
unsigned index, unsigned dimensions);
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
GcMethod*
fix a couple of OpenJDK reflection bugs We weren't wrapping exceptions thrown by invoked methods in InvocationTargetExceptions in JVM_InvokeMethod or JVM_NewInstanceFromConstructor. Also, JVM_GetCallerClass is supposed to ignore Method.invoke frames when walking the stack.
2012-09-22 20:22:33 -06:00
getCaller(Thread* t, unsigned target, bool skipMethodInvoke = false);
cache array class lookups in element class; misc. bugfixes
2010-09-25 15:54:01 -06:00
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
object
staticly type GcClassLoader instances
2014-06-28 15:11:31 -06:00
defineClass(Thread* t, GcClassLoader* loader, const uint8_t* buffer, unsigned length);
preliminary support for using OpenJDK's class library Whereas the GNU Classpath port used the strategy of patching Classpath with core classes from Avian so as to minimize changes to the VM, this port uses the opposite strategy: abstract and isolate classpath-specific features in the VM similar to how we abstract away platform-specific features in system.h. This allows us to use an unmodified copy of OpenJDK's class library, including its core classes and augmented by a few VM-specific classes in the "avian" package.
2010-09-10 15:05:29 -06:00
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
inline GcMethod*
methodClone(Thread* t, GcMethod* method)
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
{
return makeMethod
move Machine::*Type to GcObject::*Type
2014-05-28 22:17:25 -06:00
(t, method->vmFlags(),
method->returnCode(),
method->parameterCount(),
method->parameterFootprint(),
method->flags(),
method->offset(),
method->nativeID(),
method->runtimeDataIndex(),
method->name(),
method->spec(),
method->addendum(),
method->class_(),
method->code());
enable standalone OpenJDK builds As described in readme.txt, a standalone OpenJDK build embeds all libraries, classes, and other files needed at runtime in the resulting binary, eliminating dependencies on external resources.
2010-11-04 11:02:09 -06:00
}
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-29 19:00:17 -06:00
inline uint64_t
exceptionHandler(uint64_t start, uint64_t end, uint64_t ip, uint64_t catchType)
{
return (start << 48) | (end << 32) | (ip << 16) | catchType;
}
inline unsigned
exceptionHandlerStart(uint64_t eh)
{
return eh >> 48;
}
inline unsigned
exceptionHandlerEnd(uint64_t eh)
{
return (eh >> 32) & 0xFFFF;
}
inline unsigned
exceptionHandlerIp(uint64_t eh)
{
return (eh >> 16) & 0xFFFF;
}
inline unsigned
exceptionHandlerCatchType(uint64_t eh)
{
return eh & 0xFFFF;
}
inline uint64_t
lineNumber(uint64_t ip, uint64_t line)
{
return (ip << 32) | line;
}
inline unsigned
lineNumberIp(uint64_t ln)
{
return ln >> 32;
}
inline unsigned
lineNumberLine(uint64_t ln)
{
return ln & 0xFFFFFFFF;
}
code rearrangment to improve state of Android libcore tests This mainly moves several sun.misc.Unsafe method implementations from classpath-openjdk.cpp to builtin.cpp so that the Avian and Android builds can use them. It also replaces FinalizerReference.finalizeAllEnqueued with a no-op, since the real implementations assumes too much about how the VM handles (or delegates) finalization.
2013-04-23 13:47:15 -06:00
object
interruptLock(Thread* t, object thread);
void
clearInterrupted(Thread* t);
void
threadInterrupt(Thread* t, object thread);
bool
threadIsInterrupted(Thread* t, object thread, bool clear);
add optional avian.error.log system property This property may be used to specify a file name to use for printing stack traces for unhandled exceptions. The default is stderr.
2011-03-15 17:27:17 -06:00
inline FILE*
errorLog(Thread* t)
{
if (t->m->errorLog == 0) {
const char* path = findProperty(t, "avian.error.log");
if (path) {
t->m->errorLog = vm::fopen(path, "wb");
} else {
t->m->errorLog = stderr;
}
}
return t->m->errorLog;
}
JNI up the wazoo
2007-06-24 20:02:24 -06:00
} // namespace vm
rename JNIEXPORT to AVIAN_EXPORT in common.h, to avoid conflicting with jni.h
2013-11-08 08:35:10 -07:00
AVIAN_EXPORT void*
added debugging method 'vmAddressFromLine'
2009-06-11 09:45:35 -06:00
vmAddressFromLine(vm::Thread* t, vm::object m, unsigned line);
more refactoring
2007-07-06 17:50:26 -06:00
#endif//MACHINE_H
Reference in New Issue Copy Permalink