Reviewers: Vitaly,
Description:
Create a new class v8::internal::Isolate in isolate.h/isolate.cc.
Add isolate.cc to the build system.
Move code from v8::internal::V8::Initialize to Isolate::Initialize.
V8::Initialize now calls Isolate::Initialize to do almost
all of its work. From here, statics
Reviewers: Søren Gjesse,
Description:
Update comment in the API to explicitly state that the handle returned
from Context::New is persistent and has to be disposed at some point
in order to allow garbage collecting the context.
Please review this at http://codereview.chromium.org/2220003/show
I tested and added a patch for FreeBSD as well.
http://codereview.chromium.org/2282003/show
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
I forgot to add that this change is for ia32 only. ARM and x64 changes are
only
made to make them compile.
http://codereview.chromium.org/2280007/diff/1/20
File src/arm/ic-arm.cc (right):
http://codereview.chromium.org/2280007/diff/1/20#newcode293
src/arm/ic-arm.cc:293: CallModeFlag call_mode
New draft uploaded
http://codereview.chromium.org/2124022/diff/1/2
File src/arm/assembler-arm.cc (right):
http://codereview.chromium.org/2124022/diff/1/2#newcode
src/arm/assembler-arm.cc:: emit(cond | 15*B23 | B22 | B21 |
(width-1)*B16 | dst.code()*B12 |
On 2010/05/26 07:02:43, Erik Cor
Reviewers: Michail Naganov, Søren Gjesse,
Message:
r4706 broke the Solaris build due to the new OS::ReleaseStore function. This
fixes it.
Description:
Implement OS::ReleaseStore for Solaris
Please review this at http://codereview.chromium.org/2282003/show
Affected files:
M src/platform-solar
> The changes in r4687 and r4721 makes it possible to have serialization
> work
> with
> addresses.
I agree that the const pool optimization could be turned on step by step.
After having this patch in the bleeding edge, we could continue working on
the other things like the embedded object and ser
Revision: 4752
Author: mikhail.naga...@gmail.com
Date: Fri May 28 09:12:24 2010
Log: Reapply r4702 "Fix teardown order"
I accidentaly reverted changes from r4702 in r4706. Now bringing them back.
Original commit message:
As TokenEnumerator cleans up global handles posessed, it's owner --
CpuPro
Reviewers: Søren Gjesse,
Description:
Reapply r4702 "Fix teardown order"
I accidentaly reverted changes from r4702 in r4706. Now bringing them back.
Original commit message:
As TokenEnumerator cleans up global handles posessed, it's owner --
CpuProfiler must be shut down prior to global handle
Updates:
Status: Fixed
Comment #1 on issue 726 by mikhail.naganov: yey another patch for freebsd.
http://code.google.com/p/v8/issues/detail?id=726
Already fixed, see
http://code.google.com/p/v8/source/detail?spec=svn4751&r=4736
--
v8-dev mailing list
v8-dev@googlegroups.com
http://gr
http://codereview.chromium.org/2310003/diff/1/4
File src/isolate.h (right):
http://codereview.chromium.org/2310003/diff/1/4#newcode40
src/isolate.h:40: static Isolate* current();
I think we should only allow lazy initialization in the API layer.
Internally we should be able to assume the current
Updates:
Status: Fixed
Comment #2 on issue 725 by ant...@chromium.org: Named interceptor
properties should not be enumerable if query callback is missing.
http://code.google.com/p/v8/issues/detail?id=725
http://code.google.com/p/v8/source/detail?r=4751 fixes the problem on
bleeding
Status: New
Owner:
New issue 726 by vanillahsu: yey another patch for freebsd.
http://code.google.com/p/v8/issues/detail?id=726
Dear Sir:
v8 v2.2.12 does not implement OS::ReleaseStore on freebsd,
here is the patch, could you help me to review it.
thanks.
Attachments:
diff.platf
LGTM
http://codereview.chromium.org/2330003/show
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
Well, for intercepted properties we don't know anything if the
embedder does not supply a deleter interceptor. So I think what we
have here is fine - for the delete operator we don't know anything and
therefore act as if the property is not there. I think that is the
best we can do. I agree that wi
I am not insisting on DontDelete. The thing I don't like: I think
that if delete o.x returns true, then o.x must be undefined after that
(either property was present and deleted, or it wasn't present at
all).
Currently intercepted properties misbehave in this regard (but that is
an interpretation
I don't think we should change anything in connection with DontDelete
here. If you want intercepted properties to be reflected in the delete
operator you need to specify a property deleter. If you do not V8 will
act as if the property is not here (by returning true on delete).
Similarly for ReadOnl
Reviewers: Søren Gjesse,
Description:
Change the interface of LoadIC on the x64 platform to take its arguments in
registers.
Please review this at http://codereview.chromium.org/2330003/show
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/arm/ic-arm.c
Revision: 4751
Author: ant...@chromium.org
Date: Fri May 28 04:54:58 2010
Log: Make intercepted properties retrievable only by getter to be not
enumerable.
Currently if there is no query callback, V8 finds out intercepted
properties'
attributes using getter: if getter returns not empty hand
Of course. And I am going to add a layout test as well.
I wonder if we should be even more restrictive. DontDelete seems a
reasonable option for me, currently:
> var s = document.body.style
> delete s.color
true
> s.color
""
But ReadOnly is probably too much. What do you think?
yours,
anton.
Revision: 4750
Author: erik.co...@gmail.com
Date: Fri May 28 04:27:14 2010
Log: Missing file from last commit.
http://code.google.com/p/v8/source/detail?r=4750
Modified:
/branches/bleeding_edge/src/arm/codegen-arm-inl.h
===
--- /branches/bleeding_edge/src/ar
http://codereview.chromium.org/2368001/diff/1/2
File src/arm/codegen-arm.cc (right):
http://codereview.chromium.org/2368001/diff/1/2#newcode4058
src/arm/codegen-arm.cc:4058: Load(args->at(2));
On 2010/05/28 10:15:47, Søren Gjesse wrote:
Isn't SpillAll/AssertIsSpilled needed here? (I don't think
Revision: 4749
Author: erik.co...@gmail.com
Date: Fri May 28 04:23:07 2010
Log: Get rid of LoadAndSpill on ARM since Load() knows whether it is
in a spilled scope or not. Also get rid of some spilled scopes
that we don't need any more. The generators for the %_ functions,
CodeGenerator::Generate
Updates:
Status: Fixed
Comment #2 on issue 678 by ri...@chromium.org: Several cc-tests fail on
win64 due to regexp
http://code.google.com/p/v8/issues/detail?id=678
(No comment was entered for this change.)
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/
LGTM
http://codereview.chromium.org/2368001/diff/1/2
File src/arm/codegen-arm.cc (right):
http://codereview.chromium.org/2368001/diff/1/2#newcode4058
src/arm/codegen-arm.cc:4058: Load(args->at(2));
Isn't SpillAll/AssertIsSpilled needed here? (I don't think %_Log is used
when running our tests t
Reviewers: Søren Gjesse,
Description:
Get rid of LoadAndSpill on ARM since Load() knows whether it is
in a spilled scope or not. Also get rid of some spilled scopes
that we don't need any more. The generators for the %_ functions,
CodeGenerator::Generate*, are now not spilled by default. Some
Revision: 4748
Author: l...@chromium.org
Date: Fri May 28 01:37:44 2010
Log: X64: Fix issue 678. Bug in some Win64 C calls from generated code.
Win 64 C call ABI implementation requires space allocated on stack for four
argument registers, even when passing fewer arguments in registers.
Review UR
LGTM
http://codereview.chromium.org/2365001/diff/1/2
File src/x64/macro-assembler-x64.cc (right):
http://codereview.chromium.org/2365001/diff/1/2#newcode2647
src/x64/macro-assembler-x64.cc:2647: // including the ones passed in
registers, and space is alwaysallocated for
always->allocated -> alw
Reviewers: Rico,
Description:
X64: Fix issue 678. Bug in some Win64 C calls from generated code.
Win 64 C call ABI implementation requires space allocated on stack for four
argument registers, even when passing fewer arguments in registers.
Please review this at http://codereview.chromium.org/23
Oops! LGTM
http://codereview.chromium.org/2224007/show
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
30 matches
Mail list logo
