runtime/vm/runtime_entry_list.h - Issue 1315893004: Load runtime entries from the Thread instead of the ObjectPool.

Side by Side Diff: runtime/vm/runtime_entry_list.h

Issue 1315893004: Load runtime entries from the Thread instead of the ObjectPool. (Closed) Base URL: git@github.com:dart-lang/sdk.git@master

Patch Set: Created 5 years, 3 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 // Copyright (c) 2011, the Dart project authors. Please see the AUTHORS file

	2 // for details. All rights reserved. Use of this source code is governed by a

	3 // BSD-style license that can be found in the LICENSE file.

	4

	5 #ifndef VM_RUNTIME_ENTRY_LIST_H_

	6 #define VM_RUNTIME_ENTRY_LIST_H_

	7

	8 namespace dart {

	9

	10 #define RUNTIME_ENTRY_LIST(V) \

	11 V(AllocateArray) \

	12 V(AllocateContext) \

	13 V(AllocateObject) \

	14 V(BreakpointRuntimeHandler) \

	15 V(SingleStepHandler) \

	16 V(CloneContext) \

	17 V(FixCallersTarget) \

	18 V(FixAllocationStubTarget) \

	19 V(InlineCacheMissHandlerOneArg) \

	20 V(InlineCacheMissHandlerTwoArgs) \

	21 V(InlineCacheMissHandlerThreeArgs) \

	22 V(StaticCallMissHandlerOneArg) \

	23 V(StaticCallMissHandlerTwoArgs) \

	24 V(Instanceof) \

	25 V(TypeCheck) \

	26 V(BadTypeError) \

	27 V(NonBoolTypeError) \

	28 V(InstantiateType) \

	29 V(InstantiateTypeArguments) \

	30 V(InvokeClosureNoSuchMethod) \

	31 V(InvokeNoSuchMethodDispatcher) \

	32 V(MegamorphicCacheMissHandler) \

	33 V(OptimizeInvokedFunction) \

	34 V(TraceICCall) \

	35 V(PatchStaticCall) \

	36 V(ReThrow) \

	37 V(StackOverflow) \

	38 V(Throw) \

	39 V(TraceFunctionEntry) \

	40 V(TraceFunctionExit) \

	41 V(DeoptimizeMaterialize) \

	42 V(UpdateFieldCid) \

	43 V(InitStaticField) \

	44 V(GrowRegExpStack) \

	45 V(CompileFunction) \

	46 V(TestSmiSub) \
	Florian Schneider 2015/09/01 06:19:05 We don't want to have test function stored in each We don't want to have test function stored in each thread object. rmacnak 2015/09/01 17:26:54 True, but if they aren't there we need a special c Show quoted text On 2015/09/01 06:19:05, Florian Schneider wrote: > We don't want to have test function stored in each thread object. True, but if they aren't there we need a special case in emitting runtime calls that doesn't load from the thread and we are no longer testing the same mechanism. Or we need a mechanism to only include the test functions in these lists when building run_vm_tests. Florian Schneider 2015/09/02 08:22:03 Maybe we can just test runtime invocation using th Show quoted text On 2015/09/01 17:26:54, rmacnak wrote: > On 2015/09/01 06:19:05, Florian Schneider wrote: > > We don't want to have test function stored in each thread object. > > True, but if they aren't there we need a special case in emitting runtime calls > that doesn't load from the thread and we are no longer testing the same > mechanism. Or we need a mechanism to only include the test functions in these > lists when building run_vm_tests. Maybe we can just test runtime invocation using the existing functions and remove those completely then? It's not a lot of space, but seems like a bad smell, when we have unused slots for test functions here in a release build. e.g. invoke AllocateArray or LibcPow instead of calling these test-only functions. rmacnak 2015/09/02 21:58:18 Done. Show quoted text On 2015/09/02 08:22:03, Florian Schneider wrote: > On 2015/09/01 17:26:54, rmacnak wrote: > > On 2015/09/01 06:19:05, Florian Schneider wrote: > > > We don't want to have test function stored in each thread object. > > > > True, but if they aren't there we need a special case in emitting runtime > calls > > that doesn't load from the thread and we are no longer testing the same > > mechanism. Or we need a mechanism to only include the test functions in these > > lists when building run_vm_tests. > > Maybe we can just test runtime invocation using the existing functions and > remove those completely then? It's not a lot of space, but seems like a bad > smell, when we have unused slots for test functions here in a release build. > > e.g. invoke AllocateArray or LibcPow instead of calling these test-only > functions. Done.
	47

	48 #define LEAF_RUNTIME_ENTRY_LIST(V) \

	49 V(void, PrintStopMessage, const char*) \

	50 V(intptr_t, DeoptimizeCopyFrame, uword) \

	51 V(void, DeoptimizeFillFrame, uword) \

	52 V(void, StoreBufferBlockProcess, Thread*) \

	53 V(intptr_t, BigintCompare, RawBigint, RawBigint) \

	54 V(double, LibcPow, double, double) \

	55 V(double, DartModulo, double, double) \

	56 V(double, LibcFloor, double) \

	57 V(double, LibcCeil, double) \

	58 V(double, LibcTrunc, double) \

	59 V(double, LibcRound, double) \

	60 V(double, LibcCos, double) \

	61 V(double, LibcSin, double) \

	62 V(RawBool*, CaseInsensitiveCompareUC16, \

	63 RawString, RawSmi, RawSmi, RawSmi) \

	64 V(RawObject, TestLeafSmiAdd, RawObject, RawObject*) \
	Florian Schneider 2015/09/01 06:19:05 Same here. Same here.
	65

	66 } // namespace dart

	67

	68 #endif // VM_RUNTIME_ENTRY_LIST_H_

OLD	NEW

« runtime/vm/runtime_entry.h ('K') | « runtime/vm/runtime_entry_ia32.cc ('k') | runtime/vm/runtime_entry_mips.cc » ('j') | runtime/vm/runtime_entry_mips.cc » ('J')