date:20160226

Re: [v8-users] hello-world crashes under debug libraries of 4.9

2016-02-26 Thread Danny Dorfman

Sounds like a great idea, Zac. Is its use documented someplace?

On Monday, February 22, 2016 at 9:13:47 PM UTC+2, Zac Hansen wrote:
>
> It's much easier doing your testing work with the libv8_nosnapshot library 
> instead.  That way you never have to worry about it.  Startup overhead is 
> like.. fractions of a second worse - you'd have to run thousands of times 
> for it to be worse than forgetting to update your blob files once.
>
>
>
> On Thursday, February 18, 2016 at 5:33:51 AM UTC-8, Danny Dorfman wrote:
>>
>> I found out the nature of the problem. I forgot to exchange the 
>> *_blob.bin files with those of the "debug" version.
>>
>> Sorry for your trouble ...
>>
>> On Thursday, February 18, 2016 at 11:06:47 AM UTC+2, Danny Dorfman wrote:
>>>
>>> v8-version.h shows:
>>>
>>> #define V8_MAJOR_VERSION 4
>>> #define V8_MINOR_VERSION 9
>>> #define V8_BUILD_NUMBER 385
>>> #define V8_PATCH_LEVEL 18
>>>
>>> hello-world.cc was built like this:
>>> # g++ -I/usr hello-world.cc -o hello-world -Wl,--start-group 
>>> /usr/lib64/{libv8_libbase.a,libv8_libplatform.a} -Wl,--end-group -lv8 -lrt 
>>> -ldl -pthread -std=c++11
>>>
>>>
>>> On Thursday, February 18, 2016 at 10:57:25 AM UTC+2, Jochen Eisinger 
>>> wrote:

 What exact version of v8 did you use, and how did you compile hello 
 world?

 When I build with make library=shared x64.debug, executing hello_world 
 works fine for me.

 best
 -jochen

 On Wed, Feb 17, 2016 at 3:25 PM Danny Dorfman  
 wrote:

> Hello there,
>
> I successfully made an installation of the V8 4.9  stable version and 
> I am having trouble with the hello-world program.
> If I compile and link it against the "release" dynamic library, 
> everything works fine. But if I switch to "debug", I get the following 
> crash:
>
> # gdb hello-world
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show 
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /root/v8/samples/hello-world...done.
> (gdb) run
> Starting program: /root/v8/samples/hello-world 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib64/libthread_db.so.1".
> [New Thread 0x752ec700 (LWP 31545)]
> [New Thread 0x74aeb700 (LWP 31546)]
> [New Thread 0x742ea700 (LWP 31547)]
> [New Thread 0x73ae9700 (LWP 31548)]
>
> Program received signal SIGSEGV, Segmentation fault.
> v8::internal::Map::instance_type (this=0x3f5c) at 
> .././src/objects-inl.h:4424
> 4424  return static_cast(READ_BYTE_FIELD(this, 
> kInstanceTypeOffset));
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-106.el7_2.1.x86_64 libgcc-4.8.5-4.el7.x86_64 
> libstdc++-4.8.5-4.el7.x86_64
> (gdb) bt
>
> #0  v8::internal::Map::instance_type (this=0x1d24) at 
> .././src/objects-inl.h:4424
> #1  0x76f5a7e6 in v8::internal::Object::IsWeakCell 
> (this=0x19f6746c5851) at .././src/objects-inl.h:844
> #2  0x773af45b in v8::internal::WeakFixedArray::Get 
> (this=0x19f67467c7b9, index=78) at .././src/objects-inl.h:2466
> #3  0x775d8480 in v8::internal::WeakFixedArray::Remove 
> (this=0x19f67467c7b9, value=...) at ../src/objects.cc:10706
> #4  0x775e3741 in v8::internal::SharedFunctionInfo::SetScript 
> (shared=..., script_object=...) at ../src/objects.cc:13581
> #5  0x77295d10 in 
> v8::internal::Compiler::GetSharedFunctionInfo (literal=0x687548, 
> script=..., outer_info=0x7fffbed8) at ../src/compiler.cc:1676
> #6  0x77448cc7 in 
> v8::internal::FullCodeGenerator::VisitFunctionLiteral 
> (this=0x7fffbb48, 
> expr=0x687548) at ../src/full-codegen/full-codegen.cc:1295
> #7  0x76f89501 in v8::internal::FunctionLiteral::Accept 
> (this=0x687548, v=0x7fffbb48) at ../src/ast/ast.cc:28
> #8  0x774448cf in v8::internal::FullCodeGenerator::Visit 
> (this=0x7fffbb48, node=0x687548) at 
> .././src/full-codegen/full-codegen.h:961
> #9  0x77445174 in 
> v8::internal::FullCodeGenerator::VisitForAccumulatorValue 
> (this=0x7fffbb48, expr=0x687548) at 
> .././src/full-codegen/full-codegen.h:364
> #10 0x77904384 in 
> v8::internal::FullCodeGenerator::VisitFunctionDeclaration 
> (this=0x7fffbb48, declaration=0x687640) at 
>

Re: [v8-users] hello-world crashes under debug libraries of 4.9

2016-02-26 Thread Zac Hansen

you just link libv8_nosnapshot instead of libv8_external_snapshot.

You'll know you did it right when you delete the .bin files and your
program still works.



On Fri, Feb 26, 2016 at 8:54 PM, Danny Dorfman 
wrote:

> Sounds like a great idea, Zac. Is its use documented someplace?
>
>
> On Monday, February 22, 2016 at 9:13:47 PM UTC+2, Zac Hansen wrote:
>>
>> It's much easier doing your testing work with the libv8_nosnapshot
>> library instead.  That way you never have to worry about it.  Startup
>> overhead is like.. fractions of a second worse - you'd have to run
>> thousands of times for it to be worse than forgetting to update your blob
>> files once.
>>
>>
>>
>> On Thursday, February 18, 2016 at 5:33:51 AM UTC-8, Danny Dorfman wrote:
>>>
>>> I found out the nature of the problem. I forgot to exchange the
>>> *_blob.bin files with those of the "debug" version.
>>>
>>> Sorry for your trouble ...
>>>
>>> On Thursday, February 18, 2016 at 11:06:47 AM UTC+2, Danny Dorfman wrote:

 v8-version.h shows:

 #define V8_MAJOR_VERSION 4
 #define V8_MINOR_VERSION 9
 #define V8_BUILD_NUMBER 385
 #define V8_PATCH_LEVEL 18

 hello-world.cc was built like this:
 # g++ -I/usr hello-world.cc -o hello-world -Wl,--start-group
 /usr/lib64/{libv8_libbase.a,libv8_libplatform.a} -Wl,--end-group -lv8 -lrt
 -ldl -pthread -std=c++11


 On Thursday, February 18, 2016 at 10:57:25 AM UTC+2, Jochen Eisinger
 wrote:
>
> What exact version of v8 did you use, and how did you compile hello
> world?
>
> When I build with make library=shared x64.debug, executing hello_world
> works fine for me.
>
> best
> -jochen
>
> On Wed, Feb 17, 2016 at 3:25 PM Danny Dorfman 
> wrote:
>
>> Hello there,
>>
>> I successfully made an installation of the V8 4.9  stable version and
>> I am having trouble with the hello-world program.
>> If I compile and link it against the "release" dynamic library,
>> everything works fine. But if I switch to "debug", I get the following
>> crash:
>>
>> # gdb hello-world
>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> ...
>> Reading symbols from /root/v8/samples/hello-world...done.
>> (gdb) run
>> Starting program: /root/v8/samples/hello-world
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/usr/lib64/libthread_db.so.1".
>> [New Thread 0x752ec700 (LWP 31545)]
>> [New Thread 0x74aeb700 (LWP 31546)]
>> [New Thread 0x742ea700 (LWP 31547)]
>> [New Thread 0x73ae9700 (LWP 31548)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> v8::internal::Map::instance_type (this=0x3f5c) at
>> .././src/objects-inl.h:4424
>> 4424  return static_cast(READ_BYTE_FIELD(this,
>> kInstanceTypeOffset));
>> Missing separate debuginfos, use: debuginfo-install
>> glibc-2.17-106.el7_2.1.x86_64 libgcc-4.8.5-4.el7.x86_64
>> libstdc++-4.8.5-4.el7.x86_64
>> (gdb) bt
>>
>> #0  v8::internal::Map::instance_type (this=0x1d24) at
>> .././src/objects-inl.h:4424
>> #1  0x76f5a7e6 in v8::internal::Object::IsWeakCell
>> (this=0x19f6746c5851) at .././src/objects-inl.h:844
>> #2  0x773af45b in v8::internal::WeakFixedArray::Get
>> (this=0x19f67467c7b9, index=78) at .././src/objects-inl.h:2466
>> #3  0x775d8480 in v8::internal::WeakFixedArray::Remove
>> (this=0x19f67467c7b9, value=...) at ../src/objects.cc:10706
>> #4  0x775e3741 in v8::internal::SharedFunctionInfo::SetScript
>> (shared=..., script_object=...) at ../src/objects.cc:13581
>> #5  0x77295d10 in
>> v8::internal::Compiler::GetSharedFunctionInfo (literal=0x687548,
>> script=..., outer_info=0x7fffbed8) at ../src/compiler.cc:1676
>> #6  0x77448cc7 in
>> v8::internal::FullCodeGenerator::VisitFunctionLiteral 
>> (this=0x7fffbb48,
>> expr=0x687548) at ../src/full-codegen/full-codegen.cc:1295
>> #7  0x76f89501 in v8::internal::FunctionLiteral::Accept
>> (this=0x687548, v=0x7fffbb48) at ../src/ast/ast.cc:28
>> #8  0x774448cf in v8::internal::FullCodeGenerator::Visit
>> (this=0x7fffbb48, node=0x687548) at
>> .././src/full-codegen/full-codegen.h:961
>> #9  0x77445174 in
>>

[v8-users] Re: Simple loop parallelizer

2016-02-26 Thread Michael Zhou

Node, at its core, uses V8 as its JavaScript engine. What do you mean by 
"native V8"?

On Friday, February 26, 2016 at 7:07:35 PM UTC-5, Tiny Wings wrote:
>
> Thank you very much for your answer.
> Could you let me know what those showstoppers are?
> And I don't have any experience with Node and I'm not intending to build a 
> web server either. Is Node easier to use than native V8 for parallelization?
>
> Thank you.
>
> On Tuesday, February 23, 2016 at 1:31:55 PM UTC-5, 
> mog...@syntheticsemantics.com wrote:
>>
>> I, too, looked at adding OpenMP to v8 but there are several showstoppers 
>> to adding parallelism *inside* v8.  My solution was to add shared, 
>> persistent objects as a native addon, and fork multiple instances of Node 
>> for concurrency.
>>
>> The native addon prevents this from being used in browsers, but this 
>> approach works embedded in systems with POSIX-like shared memory: EMS.js 
>> home page , GitHub 
>> 
>>
>>   -J
>>
>>
>> On Monday, February 22, 2016 at 11:34:38 PM UTC-8, Tiny Wings wrote:
>>>
>>> About my question:
>>> This is actually not really much about parallelization; this is rather 
>>> about how to do launch multiple threads in multiple cores within a 
>>> javascript program and make them communicate when needed.
>>>
>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Simple loop parallelizer

2016-02-26 Thread Tiny Wings

Thank you very much for your answer.
Could you let me know what those showstoppers are?
And I don't have any experience with Node and I'm not intending to build a 
web server either. Is Node easier to use than native V8 for parallelization?

Thank you.

On Tuesday, February 23, 2016 at 1:31:55 PM UTC-5, 
mog...@syntheticsemantics.com wrote:
>
> I, too, looked at adding OpenMP to v8 but there are several showstoppers 
> to adding parallelism *inside* v8.  My solution was to add shared, 
> persistent objects as a native addon, and fork multiple instances of Node 
> for concurrency.
>
> The native addon prevents this from being used in browsers, but this 
> approach works embedded in systems with POSIX-like shared memory: EMS.js 
> home page , GitHub 
> 
>
>   -J
>
>
> On Monday, February 22, 2016 at 11:34:38 PM UTC-8, Tiny Wings wrote:
>>
>> About my question:
>> This is actually not really much about parallelization; this is rather 
>> about how to do launch multiple threads in multiple cores within a 
>> javascript program and make them communicate when needed.
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Can v8::Isolate::GetCurrent() return null?

2016-02-26 Thread Yutaka Hirano

Hi,

I'm writing a unit tests in blink and I want to check if an isolate is
disposed in a worker thread. In v8.h, v8::Isolate::GetCurrent() header
comment says

  /**
   * Returns the entered isolate for the current thread or NULL in
   * case there is no current isolate.
   *
   * This method must not be invoked before V8::Initialize() was invoked.
   */

, but in the implementation in src/isolate.h, returning null is not allowed.

Which is correct? Can I remove the DCHECK?

Thanks,

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] v8 3.28, getting data from typed arrays, I'm unsure if this approach is correct (and doesn't leak)

2016-02-26 Thread George Corney

*Correction, free(dataPtr) should be replaced with a call to your 
ArrayBufferAllocator's .Free(ptr, length) call

On Friday, February 26, 2016 at 1:22:26 PM UTC, George Corney wrote:
>
> *For the next person trying to do this:*
>
> It turns the approach in the post above doesn't completely work because 
> GetIndexedPropertiesExternalArrayData is only supported on 
> ArrayBufferViews and not ArrayBuffers. My solution now is to grab the 
> Contents::Data() pointer provided when ArrayBuffer::Externalize() is called 
> and store it on the ArrayBuffer in a hidden field (as well as creating a 
> weak persistent handle to free it later). My implementation is provided:
>
> struct WeakCallbackData{
> v8::Persistent* persistent;
> uintptr_t dataPtrValue;
> };
>
> //when we get typed array data we take responsibility for freeing the data
> void ArrayBufferWeakCallback(const v8::WeakCallbackData WeakCallbackData>& info){
> WeakCallbackData* callbackData = info.GetParameter();
> v8::Persistent* persistent = callbackData->persistent;
> void* dataPtr = (void*) info.GetParameter()->dataPtrValue;
>
> Print::Debug("ArrayBufferWeakCallback fired (byte length: %d, dataPtr*: 
> %p)", info.GetValue()->ByteLength(), dataPtr);
>
> //dealloc
> info.GetValue().Clear();
> persistent->Reset();
> delete callbackData;
> free(dataPtr);
> }
>
> void AttachPointerObject(v8::Isolate* isolate, 
> v8::Handle& buffer, void* dataPtr){
> v8::Local ptrObjTmpl = 
> v8::ObjectTemplate::New(isolate);
> ptrObjTmpl->SetInternalFieldCount(1);
> v8::Local ptrObj = ptrObjTmpl->NewInstance();
> ptrObj->SetAlignedPointerInInternalField(0, dataPtr);
> buffer->SetHiddenValue(v8::String::NewFromUtf8(isolate, "ptrObj"), ptrObj);
> }
>
> //Public API
>
> const void SafelyExternalizeArrayBuffer(v8::Isolate* isolate, 
> v8::Handle& buffer){
> if(!buffer->IsExternal()){
> v8::ArrayBuffer::Contents contents = buffer->Externalize();
> RegisterExternalData(isolate, buffer, contents.Data());
> }
> }
>
> void RegisterExternalData(v8::Isolate* isolate, 
> v8::Handle& buffer, void* dataPtr){
> Print::Debug("RegisterExternalData (byte length: %d, dataPtr*: %p)", 
> buffer->ByteLength(), dataPtr);
>
> AttachPointerObject(isolate, buffer, dataPtr);
>
> v8::Persistent* persistent = new 
> v8::Persistent();
> persistent->Reset(isolate, buffer);
>
> WeakCallbackData* callbackData = new WeakCallbackData();
> callbackData->persistent = persistent;
> callbackData->dataPtrValue = (uintptr_t)(void *)dataPtr;
>
> persistent->SetWeak(callbackData, 
> ArrayBufferWeakCallback);
> }
>
> const unsigned char* GetArrayBufferBytes(v8::Isolate* isolate, 
> v8::Handle& buffer){
> SafelyExternalizeArrayBuffer(isolate, buffer);
>
> v8::Local v = 
> buffer->GetHiddenValue(v8::String::NewFromUtf8(isolate, "ptrObj"));
>
> if(!v->IsObject()){
> Print::Error("%s: Internal data pointer not found on ArrayBuffer, ensure 
> RegisterExternalData was at initialization", __FUNCTION__);
> return NULL;
> }
>
> v8::Local ptrObj = v8::Local::Cast(v);
> const void* dataPtr = ptrObj->GetAlignedPointerFromInternalField(0);
> const unsigned char* bytePtr = static_cast(dataPtr);
> return bytePtr;
> }
>
>
> const unsigned char* GetArrayBufferViewBytes(v8::Isolate* isolate, 
> v8::Handle& bufferView){
> v8::Local buffer = bufferView->Buffer();
> SafelyExternalizeArrayBuffer(isolate, buffer);
> const void* dataPtr = bufferView->GetIndexedPropertiesExternalArrayData();
> const unsigned char* bytePtr = static_cast(dataPtr) 
> + bufferView->ByteOffset();
> return bytePtr;
> }
>
>
> (You'll need to replace the Print:: functions with whatever system you're 
> using for logging)
>
> - If the TypedArrays are coming from JS land, you'll only need 
> *GetArrayBufferBytes* and *GetArrayBufferViewBytes* (depending on if 
> you're using an ArrayBufferView or ArrayBuffer) to access the data safely
> - If the TypedArray is created in C++ land and the data buffer is provided 
> to it so it's already external, then you need to use 
> *RegisterExternalData* for to make the ArrayBuffer safe to access with 
> these functions (the buffer will be freed with the WeakCallback)
> - If you want to externalize without accessing the data, you need to use 
> *SafelyExternalizeArrayBuffer* *and not* *ArrayBuffer::Externalize()*
>
>
> All the best,
> George Corney
>
> On Monday, February 22, 2016 at 3:38:08 PM UTC, George Corney wrote:
>>
>> Thanks for the tips
>>
>> I agree regarding upgrading from 3.28, unfortunately for the time being 
>> I'm stuck with it as a consequence of various trade offs (I'm using JXcore 
>> which is built on 3.28 and I can't migrate away because of time constraints)
>>
>> I'm trying the externalize + weak persistent handle method, here's my 
>> code now
>>
>> //weak callback, frees the raw data and handle
>> void ArrayBufferWeakCallback(const v8::WeakCallbackData> v8::Persistent>& info){
>>  Print::Debug("ArrayBufferWeakCallback fired");
>>  void* rawData =

Re: [v8-users] v8 3.28, getting data from typed arrays, I'm unsure if this approach is correct (and doesn't leak)

2016-02-26 Thread George Corney

*For the next person trying to do this:*

It turns the approach in the post above doesn't completely work because 
GetIndexedPropertiesExternalArrayData is only supported on ArrayBufferViews 
and not ArrayBuffers. My solution now is to grab the Contents::Data() 
pointer provided when ArrayBuffer::Externalize() is called and store it on 
the ArrayBuffer in a hidden field (as well as creating a weak persistent 
handle to free it later). My implementation is provided:

struct WeakCallbackData{
v8::Persistent* persistent;
uintptr_t dataPtrValue;
};

//when we get typed array data we take responsibility for freeing the data
void ArrayBufferWeakCallback(const v8::WeakCallbackData& info){
WeakCallbackData* callbackData = info.GetParameter();
v8::Persistent* persistent = callbackData->persistent;
void* dataPtr = (void*) info.GetParameter()->dataPtrValue;

Print::Debug("ArrayBufferWeakCallback fired (byte length: %d, dataPtr*: 
%p)", info.GetValue()->ByteLength(), dataPtr);

//dealloc
info.GetValue().Clear();
persistent->Reset();
delete callbackData;
free(dataPtr);
}

void AttachPointerObject(v8::Isolate* isolate, v8::Handle& 
buffer, void* dataPtr){
v8::Local ptrObjTmpl = v8::ObjectTemplate::New(isolate);
ptrObjTmpl->SetInternalFieldCount(1);
v8::Local ptrObj = ptrObjTmpl->NewInstance();
ptrObj->SetAlignedPointerInInternalField(0, dataPtr);
buffer->SetHiddenValue(v8::String::NewFromUtf8(isolate, "ptrObj"), ptrObj);
}

//Public API

const void SafelyExternalizeArrayBuffer(v8::Isolate* isolate, 
v8::Handle& buffer){
if(!buffer->IsExternal()){
v8::ArrayBuffer::Contents contents = buffer->Externalize();
RegisterExternalData(isolate, buffer, contents.Data());
}
}

void RegisterExternalData(v8::Isolate* isolate, 
v8::Handle& buffer, void* dataPtr){
Print::Debug("RegisterExternalData (byte length: %d, dataPtr*: %p)", 
buffer->ByteLength(), dataPtr);

AttachPointerObject(isolate, buffer, dataPtr);

v8::Persistent* persistent = new 
v8::Persistent();
persistent->Reset(isolate, buffer);

WeakCallbackData* callbackData = new WeakCallbackData();
callbackData->persistent = persistent;
callbackData->dataPtrValue = (uintptr_t)(void *)dataPtr;

persistent->SetWeak(callbackData, 
ArrayBufferWeakCallback);
}

const unsigned char* GetArrayBufferBytes(v8::Isolate* isolate, 
v8::Handle& buffer){
SafelyExternalizeArrayBuffer(isolate, buffer);

v8::Local v = 
buffer->GetHiddenValue(v8::String::NewFromUtf8(isolate, "ptrObj"));

if(!v->IsObject()){
Print::Error("%s: Internal data pointer not found on ArrayBuffer, ensure 
RegisterExternalData was at initialization", __FUNCTION__);
return NULL;
}

v8::Local ptrObj = v8::Local::Cast(v);
const void* dataPtr = ptrObj->GetAlignedPointerFromInternalField(0);
const unsigned char* bytePtr = static_cast(dataPtr);
return bytePtr;
}


const unsigned char* GetArrayBufferViewBytes(v8::Isolate* isolate, 
v8::Handle& bufferView){
v8::Local buffer = bufferView->Buffer();
SafelyExternalizeArrayBuffer(isolate, buffer);
const void* dataPtr = bufferView->GetIndexedPropertiesExternalArrayData();
const unsigned char* bytePtr = static_cast(dataPtr) + 
bufferView->ByteOffset();
return bytePtr;
}


(You'll need to replace the Print:: functions with whatever system you're 
using for logging)

- If the TypedArrays are coming from JS land, you'll only need 
*GetArrayBufferBytes* and *GetArrayBufferViewBytes* (depending on if you're 
using an ArrayBufferView or ArrayBuffer) to access the data safely
- If the TypedArray is created in C++ land and the data buffer is provided 
to it so it's already external, then you need to use *RegisterExternalData* 
for to make the ArrayBuffer safe to access with these functions (the buffer 
will be freed with the WeakCallback)
- If you want to externalize without accessing the data, you need to use 
*SafelyExternalizeArrayBuffer* *and not* *ArrayBuffer::Externalize()*


All the best,
George Corney

On Monday, February 22, 2016 at 3:38:08 PM UTC, George Corney wrote:
>
> Thanks for the tips
>
> I agree regarding upgrading from 3.28, unfortunately for the time being 
> I'm stuck with it as a consequence of various trade offs (I'm using JXcore 
> which is built on 3.28 and I can't migrate away because of time constraints)
>
> I'm trying the externalize + weak persistent handle method, here's my code 
> now
>
> //weak callback, frees the raw data and handle
> void ArrayBufferWeakCallback(const v8::WeakCallbackData v8::Persistent>& info){
>  Print::Debug("ArrayBufferWeakCallback fired");
>  void* rawData = info.GetValue()->GetIndexedPropertiesExternalArrayData();
>  info.GetValue().Clear();
>  info.GetParameter()->Reset();
>  free(rawData);
>  free(info.GetParameter());
> }
>
>
> //...
>
>
> v8::Local bufferView = dataArg.As >();
> size_t byteLength = bufferView->ByteLength();
> size_t byteOffset = bufferView->ByteOffset();
>
>
> bufferView->Buffer()->Externalize();
>
>
> //create weak persistent handle with callback to above code
>

Re: [v8-users] hello-world crashes under debug libraries of 4.9

Re: [v8-users] hello-world crashes under debug libraries of 4.9

[v8-users] Re: Simple loop parallelizer

[v8-users] Re: Simple loop parallelizer

[v8-users] Can v8::Isolate::GetCurrent() return null?

Re: [v8-users] v8 3.28, getting data from typed arrays, I'm unsure if this approach is correct (and doesn't leak)

Re: [v8-users] v8 3.28, getting data from typed arrays, I'm unsure if this approach is correct (and doesn't leak)

7 matches

Site Navigation

Mail list logo

Footer information